View QG80331M500_6606435.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

intel ? 80331 i/o processor specification update april 2006 the intel ? 80331 i/o processor may contain design defects or errors known as errata that may cause the product to deviate from published specifications. current characterized errata are doc- umented in this specification update. order number: 273930-021us
2 specification update information in this document is provided in connection with intel ? products. except as provided in intel?s terms and conditions of sale for such products, intel assumes no liability whatsoever, and intel disclaims any express or implied warranty relating to sale and/or use of intel products, including liability or warranties relating to fitness for a particular purpose, merchantability, or infringement of any patent, copyright, or other intellectual property right. intel corporation may have patents or pending patent applications, trademarks, copyrights, or other intellectual property right s that relate to the presented subject matter. the furnishing of documents and other materials and information does not provide any license, express or implied, by estoppel or otherwise, to any such patents, trademarks, copyrights, or other intellectual property rights. intel products are not intended for use in medical, life saving , life sustaining, critical control or safety systems, or in nuc lear facility applications. intel may make changes to specifications and product descriptions at any time, without notice. designers must not rely on the absence or characteristics of any features or instructions marked ?reserved? or ?undefined.? int el reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. contact your local intel sales office or your distributor to obtain the latest specifications and before placing your product o rder. copies of documents which have an ordering number and are referenced in this document, or other intel literature may be obtaine d by calling 1-800-548-4725 or by visiting intel's website at http://www.intel.com . intel, intel logo, and intel xscale are trademarks or registered trademarks of intel corporation or its subsidiaries in the uni ted states and other countries. *other names and brands may be claimed as the property of others. copyright ? 2006, intel corporation
specification update 3 intel ? 80331 i/o processor contents revision history ......................................................................................... 5 preface....................................................................................................... 8 summary table of changes....................................................................... 9 identification information.......................................................................... 17 non-core errata....................................................................................... 19 core errata .............................................................................................. 43 specification changes ............................................................................. 47 specification clarifications ....................................................................... 51 documentation changes ......................................................................... 61
4 specification update intel ? 80331 i/o processor this page intentionally left blank. this page intentionally left blank
specification update 5 revision history date version description april 2006 021 added: ? d-1 stepping information to all summary tables and to table 1, ?intel ? 80331 i/o processor die details? on page 17 and table 2, ?intel ? 80331 i/o processor device id registers? on page 18 ? status change of erratum 62 ? status change of specification change 22 ? status change of specification clarification 33 february 2006 020 added: ? non-core errata 63 ? specification clarification 33 january 2006 019 added: ? non-core errata 62 ? specification change 22 december 2005 018 added: ? specification clarification 31 and 32 ? documentation change 17 october 2005 017 added: ? specification clarification 29 and 30 august 2005 016 added: ? specification clarification 27 and 28 ? documentation change 16 . june 2005 015 added: ? non-core errata 61 may 2005 014 added: ? non-core errata 60 ? specification change 21 updated: ? specification change 13 , 15 , and 16 april 2005 013 added: ? non-core errata 58 and 59 march 2005 012 added: ? specification change 19 and 20 ? documentation change 15 ? pb-free markings to table 1, ?intel ? 80331 i/o processor die details? on page 17 updated: ? non-core errata 4 ? updated non-core errata 50 changed: ? status of non-core errata 20 to fixed
6 specification update intel ? 80331 i/o processor revision history january 2005 011 added: ? non-core errata 57 ? specification clarification 26 ? documentation change 13 and 14 november 2004 010 added: ? non-core errata 56 ? specification clarification 25 september 2004 009 added: ? specification clarification 23 and 24 . ? specification change 18 . ? documentation change 12 . updated: ? specification change 11 and specification clarifications 13 and 22 . august 2004 008 added: ? d-0 stepping information. ? non-core errata 55 . ? specification clarification 21 and 22 . ? specification change 17 . updated: ? non-core errata 51 and 54 . june 2004 007 added: ? non-core errata 52 through 54 . ? specification clarification 19 and 20 . ? documentation change 11 . may 2004 006 added: ? non-core errata 49 through 51 ? specification clarification 17 and 18 ? specification change 14 through 16 ? documentation change 10 updated: ? spec change 12 ; spec clarification 13 april 2004 005 added: ? non-core errata 46 through 48 . ? specification clarification 13 through 16 . ? documentation change 8 and 9 . ? added c-1 to errata table updated: ? non-core errata 45 . ? specification change 11 . ? specification clarification 11 and 12 . ? documentation change 3 . ? status information for non-core errata. date version description
specification update 7 intel ? 80331 i/o processor revision history march 2004 004 added: ? errata 37 through 45 . ? specification change 10 through 13 . ? specification clarification 9 through 12 . ? documentation change 5 through 7 . updated: ? erratum 35 . january 2004 003 added: ? errata 33 through 36 . ? specification change 9 . ? specification clarification 8 . ? documentation change 3 and 4 . updated: ? erratum 31 . november 2003 002 added: ? errata 27 through 32 . ? specification changes 7 and 8 . ? specification clarification 6 and 7 . ? documentation changes 1 and 2 . updated: ? errata 6 , 21 and 26 . september 2003 001 initial release. date version description
8 specification update intel ? 80331 i/o processor preface preface this document is an update to the specifications contained in the affected documents/related documents table below. this document is a compilation of device and documentation errata, specification clarifications and changes. it is intended for hardware system manufacturers and software developers of applications, operating systems, or tools. information types defined in nomenclature are consolidated into the specification update and are no longer published in other documents. this document may also contain information that was not previously published. affected documents/related documents nomenclature errata are design defects or errors. these may cause the intel ? 80331 i/o processor 1 behavior to deviate from published specifications. hardware and software designed to be used with any given stepping must assume that all errata documented for that stepping are present on all devices. specification changes are modifications to the current pu blished specifications. these changes will be incorporated in any new release of the specification. specification clarifications describe a specification in greater detail or further highlight a specification?s impact to a complex design situation. these clarifications will be incorporated in any new release of the specification. documentation changes include typos, errors, or omissions from the current published specifications. these will be incorporated in any new release of the specification. note: errata remain in the specification update throughout the product?s lifecycle, or until a particular stepping is no longer commercia lly available. under these circumstances, errata removed from the specification update are archived and available upon request. specification changes, specification clarifications and documentation changes are re moved from the specification update when the appropriate changes are made to the appropri ate product specification or user documentation (datasheets, manuals, etc.). title order intel ? 80331 i/o processor developer?s manual 273942 intel ? 80331 i/o processor datasheet 273943 intel ? 80331 i/o processor design guide 273823 1. arm* architecture compliant.
specification update 9 intel ? 80331 i/o processor summary table of changes summary table of changes the following table indicates the errata, specifi cation changes, specification clarifications, or documentation changes which apply to the intel ? 80331 i/o processor. intel may fix some of the errata in a future stepping of the component, and account for the other outstanding issues through documentation or specification changes as noted. this table uses the following notations: codes used in summary table stepping x: errata exists in the stepping indicated. specification change or clarification that applies to this stepping. (no mark) or (blank box): this erratum is fixed in listed stepping or specification change does not apply to listed stepping. page (page): page location of it em in this document. status doc: document change or update will be implemented. plan fix: this erratum may be fixed in a future stepping of the product. fixed: this erratum has been previously fixed. no fix: there are no plans to fix this erratum. row change bar to left of table row indicates this erratum is either new or modified from the previous version of the document.
10 specification update intel ? 80331 i/o processor summary table of changes non-core errata (sheet 1 of 3) no. steppings page status errata a-1 b-0 c-0 c-1 d-0 d-1 1 xxxxxx 19 no fix cas latency of three not supported for ddr-ii on-die termination (odt) 2 x 19 fixed upper pci signals on secondar y pci bus are not driven low during reset 3 x 19 fixed memory controller unit does not properly support 32-bit memory configurations 4 xxxxxx 19 no fix legacy power fail mechanism does not work 5 x 20 fixed boundary scan data gets inverted 6 x 20 fixed biu interrupt does not occur on internal bus write master abort 7 x 20 fixed crc value calculated by dma unit is not compliant with iscsi 8 x 20 fixed atu outbound direct window overlaps with pbi exception vectors 9 xxxxxx 20 no fix s_req64# initialization pattern timing violation in pci-33 mode 10 x 21 fixed pci-66 mode violates pci ac timings 11 x 21 fixed reserved bits in the modem status register incorrectly generate interrupts 12 x 21 fixed p_req# not de-asserted during idle 13 x 21 fixed chassis/slot pci extended capability is not valid 14 x 22 fixed sdcr0.2 implemented as ?reserved? 15 x 22 fixed 32-bit region missing proper address decode 16 x 22 fixed s_gnt[3:2]# outputs are not pulled high when bridge is disabled. 17 xxxxxx 22 no fix split transaction commitment limit register mechanism, in the pci-x bridge, does not operate as implied by the pci-x addendum to the pci local bus specification, revision 1.0a 18 xxxxxx 23 no fix watchdog time-outs by the pci-x bridge may cause data corruption 19 x 23 fixed discard timer expiration on delayed read can cause data corruption or deadlock when data is still being received on target bus 20 x 23 fixed configuration cycle attribute parity error signaled incorrectly by pci-x bridge 21 xx 23 fixed transactions are buffered during secondary reset 22 x 24 fixed primary bus pin mode behavior incorrect during reset in the 80331 no bridge mode 23 x 24 fixed p_req# pin mode behavior when in the 80331 no bridge mode 24 xx 24 fixed master abort after data transfer within a single adb on pci-x to pci-x read block transactions may cause data corruption or deadlock
specification update 11 intel ? 80331 i/o processor summary table of changes 25 xxxxxx 25 no fix boundary scan multi-chip module implementation 26 xxxxxx 25 no fix auto refresh command also generates a precharge all command on ddr bus 27 x 26 fixed serr# set to incorrect voltage 28 x 26 fixed m66en set to incorrect voltage 29 x 26 fixed p_int[d:a]# not operating correctly 30 x 26 fixed secondary bus may not initialize correctly at 100 mhz pci-x or 133 mhz pci-x 31 xxxxxx 26 no fix coalesced writes to 32-bi t memory can cause data corruption 32 xxxxxx 27 no fix atu passing rules operation in pci mode 33 xx 27 fixed s_int[d:a]# pull-ups disabled by internal bus reset 34 xx 27 fixed mcu preemption control does not properly manage the byte count 35 xx 28 fixed i 2 c unit hang condition 36 xxxxxx 28 no fix vpd data register bit 19 is not read/write 37 xx 29 fixed intel xscale ? core lockup condition 38 xx 30 fixed 32-bit region write corrupts ecc immediately after 64-bit read-modify-write 39 x 30 fixed reset straps incorrectly sampled on the secondary reset 40 xx 31 fixed pci-x to pci memory read double-word near 1mb boundary may cause the system to hang 41 xx 31 fixed pci-x to pci memory read block across 1mb boundary may cause data corruption 42 xxxxxx 32 no fix dma crc result is byte reversed 43 xxxxxx 32 no fix crc corruption on pci-to-local dma transfers 44 xxxx 32 fixed byte count modified bit set to 1 45 xxxx 33 fixed corrupted byte count and data when crossing 1 mbyte boundary in pci-x to pci mode 46 xxxx 33 fixed pci-x to pci memory read with 4 k byte count and unaligned starting address 47 xxx 34 fixed vccddr (vcc25/vcc18) current spike 48 xxxx 35 fixed bridge pci ordering rule violation 49 xxxxxx 35 no fix atu claims pci commands 8 and 9 when issued as dual address cycle (dac) 50 xxxxxx 36 no fix secondary bus pci rst# pulse prior to the rising edge of p_rst# 51 xx 36 fixed slow edge rates observed when 80331 is driving the primary bus 52 xxxx 37 fixed enabling the core-to-memory port can cause a stall condition non-core errata (sheet 2 of 3) no. steppings page status errata a-1 b-0 c-0 c-1 d-0 d-1
12 specification update intel ? 80331 i/o processor summary table of changes 53 xxxxxx 38 no fix pci-to-pci read flow-through with destination trdy# stalls can cause data corruption 54 xxxx 38 fixed s_pcixcap pci mode threshold is too high 55 xxxxxx 39 no fix no support for burst i/o and configuration read/writes 56 xxxxxx 39 no fix read flow through hangs due to disconnect without data at a buffer boundary. 57 xxxxxx 39 no fix p_serr# not asserted for parity error on ad[63:32] 58 xxxxxx 39 no fix bus interface unit (biu) claims dac addresses in the range of the memory mapped registers (mmr 59 xxxxxx 40 no fix pcix-to-pci memory read issued as 32-bit, then retried as 64-bit 60 xxxxxx 41 no fix tc1(min) of the pci-x clock observed to be marginally less than the requirement specified for the pci-x (mode 1, class1) clock jitter. 61 xxxxxx 41 no fix i2c control register reset bit does not function 62 x 41 fixed internal clock misalignment can cause processor hang. 63 xxxxxx 41 no fix spurious dma0 end-of-transfer interrupt non-core errata (sheet 3 of 3) no. steppings page status errata a-1 b-0 c-0 c-1 d-0 d-1
specification update 13 intel ? 80331 i/o processor summary table of changes core errata no. steppings page status errata a-1 b-0 c-0 d-0 d-1 1 xxxx x 43 no fix abort is missed when lock command is outstanding 2 xxxx x 43 no fix aborted store that hits the data cache may mark write-back data as dirty 3 xxxx x 44 no fix performance monitor unit event 0x1 can be incremented erroneously by unrelated events 4 xxxx x 44 no fix in special debug state, back-to-back memory operations ? where the first instruction aborts ? may cause a hang 5 xxxx x 45 no fix accesses to the cp15 id register with opcode2 > 0b001 returns unpredictable values 6 xxxx x 45 no fix disabling and re-enabling the mmu can hang the core or cause it to execute the wrong code 7 xxxx x 46 no fix updating the jtag parallel registers requires an extra tck rising edge 8 xxxx x 46 no fix non-branch instruction in vector table may execute twice after a thumb mode exception
14 specification update intel ? 80331 i/o processor summary table of changes specification changes no. steppings page status specification changes a-1 b-0 c-x d-0 d-1 1 xxxx x 47 doc hpi# (high priority interrupt) is a maskable interrupt 2 xxxx x 47 doc pciodt_en reset strap signal 3 xxxx x 47 doc lock# functionality has been de-featured 4 xxxx x 47 doc watchdog timer and retry timer has been de-featured 5 xxx x 47 doc p_gnt# and p_req# signals have new ball locations on b-0 6 xxxx x 47 doc peripheral performance monitor unit has been de-featured 7 xxxx x 48 doc processor device id has been removed 8 xxxx x 48 doc 1.5k pull-down required on ad[15] of the pbi bus 9 xxxx x 48 doc ocd and receive enable calibration de-featured 10 xxx x 48 doc new watchdog timer (wdt) functionality in b-0 stepping 11 xxxx x 48 doc pwrdelay needs only a pull-up for battery back-up mode 12 xxxx x 48 doc arb_en signal has been de-featured 13 xxxx x 48 doc intel? 80331 i/o processor design guide change for unbuffered ddr-i dual-banked dimms 14 xxxx x 48 doc ddrres2 can be pulled down to reduce current during self-refresh 15 xxxx x 48 doc intel? 80331 i/o processor design guide change for peripheral bus interface (pbi) 16 xxxx x 49 doc intel? 80331 i/o processor design guide change for pci/-x busses 17 xx 49 doc internal bus operates at 333 mhz for d-0 stepping 18 xx 49 doc application accelerator unit enhanced for d-0 stepping 19 xxxx x 49 doc recommended dll register values 20 xxxx x 49 doc ddr-ii jedec initialization sequence includes writes to emrs2 and emrs3 21 xxxx x 50 doc case temperature (tcase) change 22 x 50 fixed internal clock misalignment.
specification update 15 intel ? 80331 i/o processor summary table of changes specification clarifications no. steppings page status specification clarifications a-1 b-0 c-x d-0 d-1 1 xxxx x 51 no fix 64 mb and 2 gb ddr333 capacities not to be tested in post-silicon validation 2 xxxx x 51 no fix ddr-ii 400 unbuffered dimms are not supported 3 xxxx x 51 no fix interrupt behavior in the 80331 no bridge mode 4 xxxx x 51 no fix memory map for 2 gbyte of ddr memory 5 xxxx x 51 no fix back to back mcu mmr reads 6 xxxx x 52 no fix write requirements for the peripheral bus interface 7 xxxx x 52 no fix pci-x status register during pci mode 8 xxxx x 52 no fix m_rst# driven to ddr-ii or ddr-i voltage levels 9 xxxx x 52 no fix biu master abort causes two interrupts on reads. 10 xxxx x 53 no fix reset internal bus (pcsr.5) usage 11 xxxx x 53 no fix no bridge mode (brg_en) validation 12 xxxx x 53 no fix potential race condition with interrupt controller unit status bits 13 xxxx x 54 no fix bus interface unit follows pci ordering rules 14 xxxx x 55 no fix uart, i 2 c and gpio memory mapped registers should be addressed with 32-bit accesses 15 xxxx x 55 no fix flash wait states 16 xxxx x 55 no fix uart interrupt identification register 17 xxxx x 55 no fix reads on 16-bit pbi bus operate as 32-bit 18 xxxx x 56 no fix embedded design usage model - secondary pci bus only 19 xxxx x 56 no fix 3.3 v to 1.5 v leakage 20 xxxx x 56 no fix accessing ?reserved? registers in ?no bridge? mode 21 xxxx x 56 no fix power plane isolation for battery back-up (bbu) mode 22 xxxx x 57 no fix aau result can be written directly to pci host memory 23 xxxx x 57 no fix pwrdelay functionality during power sequencing 24 xxxx x 57 no fix pbi lockout condition 25 xx 57 no fix interleaving descriptors with d-0 aau 26 xxxx x 58 no fix rcvdly setting for ddr-i memory 27 xxxx x 58 no fix atubar3 functionality 28 xxxx x 58 no fix vref isolation for battery back-up (bbu) mode 29 xxxx x 58 no fix i2c unit enabling 30 xxxx x 59 no fix dma transactions from local memory to a conventional pci target can complete out of order 31 xxxx x 59 no fix sbr1 programming with bank 1 unpopulated 32 xxxx x 59 no fix 32-bit writes to unaligned 64-bit addresses are promoted to 64-bit aligned writes 33 xxxx 60 fixed case temperature clarification.
16 specification update intel ? 80331 i/o processor summary table of changes documentation changes no. document revision page status documentation changes 1 273942-002 61 doc table 236 shows incorrect description for twdl field 2 273942-002 61 doc processor device id should be removed 3 273942-002 61 doc core performance monitoring unit (cpmon) section is incorrect 4 273942-002 61 doc uart fifo occupancy register is read only 5 273942-002 61 doc refresh frequency register table is incorrect 6 273942-002 61 doc pbi interrupt should be removed 7 273942-002 62 doc arb_en has been de-featured 8 273942-002 62 doc flash wait state information is incorrect 9 273942-002 63 doc sdcr0 and sdcr1 register updates 10 273823-001 66 doc power sequence timing 11 273943-001 66 doc updated peripheral bus interface (pbi) timings 12 273942-002 66 doc atu pm_cap[5] text must be updated 13 273942-002 67 doc wdtcr also affected by tmr1[3] 14 273942-002 67 doc split completion message clarification 15 273823-002 67 doc figure 49 in design guide shows incorrect trace length 16 273943-001 67 doc wrong voltage values in table 21 17 273942-002 67 doc sbr1 programming when bank 1 is unpopulated
specification update 17 intel ? 80331 i/o processor identification information identification information die details table 1. intel ? 80331 i/o processor die details stepping part number qdf (q)/ specification number (sl) processor speed (mhz) notes a-1 nq80331m500 q623 500 engineering samples b-0 nq80331m500 q651 500 engineering samples c-0 nq80331m500 q723 500 engineering samples c-0 nq80331m667 q726 667 engineering samples c-0 nq80331m800 q729 800 engineering samples c-1 nq80331m500 q870 500 engineering samples c-1 nq80331m667 q871 667 engineering samples c-1 nq80331m800 q872 800 engineering samples c-1 nq80331m500 sl7nm, sl82r 500 production c-1 nq80331m667 sl7nn, sl82s 667 production c-1 nq80331m800 sl7np, sl82t 800 production d-0 nq80331m500 QG80331M500 q006 q105 500 engineering samples pb-free eng samples d-0 nq80331m667 qg80331m667 q007 q106 667 engineering samples pb-free eng samples d-0 nq80331m800 qg80331m800 q008 q107 800 engineering samples pb-free eng samples d-0 nq80331m500 QG80331M500 sl823 (tray), sl827 (t&r) sl8c5 (tray), sl8c9 (t&r) 500 production pb-free production d-0 nq80331m667 qg80331m667 sl824 (tray), sl828 (t&r) sl8c6 (tray), sl8ca (t&r) 667 production pb-free production d-0 nq80331m800 qg80331m800 sl825 (tray), sl829 (t&r) sl8c7 (tray), sl8cb (t&r) 800 production pb-free production d-1 nq80331m500 QG80331M500 q604 q608 500 engineering samples pb-free eng samples d-1 nq80331m667 qg80331m667 q605 q609 667 engineering samples pb-free eng samples d-1 nq80331m800 qg80331m800 q606 q610 800 engineering samples pb-free eng samples
18 specification update intel ? 80331 i/o processor identification information d-1 nq80331m500 QG80331M500 sl9b7 sl9be 500 production pb-free production d-1 nq80331m667 qg80331m667 sl9b8 sl9bf 667 production pb-free production d-1 nq80331m800 qg80331m800 sl9b9 sl9bg 800 production pb-free production table 2. intel ? 80331 i/o processor device id registers device and stepping processor device id (cp15, register 0 ? opcode_2=0) revision id jtag device id and pdir a-1 0x69054090 0x00 0x09279013 b-0 0x69054094 0x04 0x49279013 c-0 0x69054096 0x06 0x69279013 c-1 0x69054097 0x07 0x69279013 d-0 0x6905409a 0x0a 0xa9279013 d-1 0x6905409a 0x0a 0xa9279013 note: processor core speed can be identified by reading cclkcfg[3:0] (cp14, register 6) 500 mhz = 0x0, 667 mhz = 0x2, 800 mhz = 0x4 table 1. intel ? 80331 i/o processor die details stepping part number qdf (q)/ specification number (sl) processor speed (mhz) notes
specification update 19 intel ? 80331 i/o processor non-core errata non-core errata 1. cas latency of three not supported for ddr-ii on-die termination (odt) problem: for ddr-ii memory with a cas latency (cl) of three, the memory controller unit (mcu) does not provide the proper timing for the on-die termination signals (odt[1:0]). the jedec ddr-ii sdram specification , september 2002, states that odt must be driven one cycle prior to the write command, but the mcu does not meet this timing. implication: cas latency of 3 is not supported in the 80331, therefore minimal performance impact as compared to cas latency of 4. workaround: use cas latency = 4 or do not use odt feature. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 2. upper pci signals on secondary pci bus are not driven low during reset problem: pci requires the central resource to provide valid logic states on ad[63:32], c/be[7:4]# and par64 during reset, and that they may only be driven to zero. the s_ad[63:32], s_c/be[7:4]#, s_par64 on the secondary pci bus are not driven to zero during secondary bridge pci-x initialization; instead, these pins are tri-stated, ?z?. this is not a violation of the pci local bus specification , revision 2.3. implication: some pci targets may not operate correctly, wh en they require these signals to be zero during reset. workaround: no workaround. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 3. memory controller unit does not properly support 32-bit memory configurations problem: the memory controller unit (mcu) incorrectly stores the row address used in the page miss/page hit look up table. the result of this can cause the mcu to incorrectly determine a page hit or miss. when this occurs, it causes aliasing to an incorrect row of ddr sdram. implication: 32-bit memory cannot be used with a-1 stepping. workaround: no workaround. use a 64-bit memory subsystem. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 4. legacy power fail mechanism does not work problem: for previous i/o processor generations, an external clock was required to maintain the incoming pci clock (p_clk) long enough for the power fail sequence to be sent to the memory. this is what is referred to as ?legacy power fail?. the internal control circuit that enab les the legacy power fail method is broken. implication: legacy power fail cannot be used. workaround: for 80331, a new feature was added which keeps internal clocks running on power fail. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 .
20 specification update intel ? 80331 i/o processor non-core errata 5. boundary scan data gets inverted problem: data driven in during boundary scan gets inverted during the capture phase. during parallel loading on a pin, an external zero on data in gets inverted to one for data out. this is a violation of the ieee 1149.1 specification . implication: boundary scan cannot be used with a-1 stepping. workaround: no workaround. do not use boundary scan. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 6. biu interrupt does not occur on internal bus write master abort issue: software developers be aware that an interrupt is not generated when the bus interface unit gets master aborted on an internal bus write. implication: when left undetected, it could cause data corruption. workaround: the status bit needs to be polled by software. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 7. crc value calculated by dma unit is not compliant with iscsi problem: several issues with the crc generation engine have caused it to not be compliant with iscsi in a-1 step. implication: crc cannot be used with a-1 stepping. workaround: no workaround. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 8. atu outbound direct window overlaps with pbi exception vectors problem: when the pbi exception vectors are enabled (pbcr.3), it claims addresses 00h-3fh. when the atu outbound direct window is enabled, it claims addresses 28h-7fffffffh. there is an overlap between 28h-3fh, where both devices claim the intern al bus transaction. for writes, this may not be an issue, since the only transaction here is a posted write to the atu. for reads, the pbi handles the transaction as a single data phase disconnect, and the atu internally handles it as a split transaction. implication: the agent which issued th e internal bus transaction does not claim the returning data, since the transaction has been completed by the pbi. this cau ses the data from pci to not be returned to the issuing internal bus agent. workaround: consider address range of 28h-3fh reserved. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 9. s_req64# initialization pattern timing violation in pci-33 mode problem: the pci local bus specification , revision 2.3 states rst# to req64# hold time is 0 ns minimum and 50 ns maximum. the 80331 drives the req64# signal for three cycles after rst# deasserts. therefore, in pci-33 mode, this is 90 ns, which violates the 50 ns maximum. all other pci and pci-x modes are within the specification (i.e., pci-66 is 45 ns). implication: some pci targets may not interpret the req64# signal correctly, causing it to operate in 32-bit mode. workaround: when running in pci-33 mode, make sure pci target can handle the extra 40 ns. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 .
specification update 21 intel ? 80331 i/o processor non-core errata 10. pci-66 mode violates pci ac timings problem: the pci local bus specification , revision 2.3 states a setup time of 3 ns for pci-66 mode. the 80331 a-1 step has estimated the setup time to be in the range of 3.5 ns to 4 ns, which violates the pci local bus specification , revision 2.3. implication: some pci 66 mhz targets may not function correctly with a-1 stepping. workaround: use pci-33 or pci-x modes for initial development on a-1 stepping. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 11. reserved bits in the modem status register incorrectly generate interrupts problem: bits[3:1] in the uart modem status register ar e reserved bits. these rese rved bits are incorrectly tied to the asserted state therefore generate fals e interrupts when the modem interrupt enable bit (uxier.3) is set. however, the reserved bits only generate the false interrupt once. this happens the cycle after the uart unit is enabled (uxier .6) and the modem status interrupts are enabled (uxier.3). once the modem interrupt register is read no more false interrupts occur. implication: a false interrupt can occur. workaround: software needs to read the modem status register to determine proper interrupt sources. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 12. p_req# not de-asserted during idle problem: the p_req# signal stays asserted during bus idle instead of de-asserting as required by pci local bus specification , revision 2.3. for example, when a pci target asserts stop#, the p_req# signal de-asserts one clock later than it should. the p_req# should have been de-asserted during the idle cycle. implication: may cause conflict with other pci agents. workaround: use a system arbiter that doe s not care when this condition occurs. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 13. chassis/slot pci extended capability is not valid problem: the chassis/slot pci extended capability canno t be configured, and therefore the capability is not valid and needs to be removed from the capability chain. the chassis/slot capability registers at d4h - d7h needs to be listed as reserved. implication: invalid capability information provided to the host. workaround: do not use chassis/slot pci extended capability. status: fixed. fixed in b-0 stepping. the fix is to change the capability pointer at 34h to point to the next capability pointer (power management) at dch, instead of d4h. d4h is to return zero when read. see the table , ?summary table of changes? on page 9 .
22 specification update intel ? 80331 i/o processor non-core errata 14. sdcr0.2 implemented as ?reserved? problem: the attribute for bit 2 in the mcu sdram control register 0 (sdcr0) is incorrectly implemented as ?reserved?, instead of ?read only?. since it is ?reserved?, software cannot rely on reading this bit to determine when ddr or ddr-ii memory type is selected. the external state of mem_type can not be correctly identified by reading this bit. implication: this bit cannot be used to determine memory type. workaround: since hardware design is specific to e ither ddr or ddr-ii, software engineers know what memory is being used in their application and therefore need not rely on this bit. also, software can read dimm information via serial presence detect (spd). status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 15. 32-bit region missing proper address decode problem: when connected to 64-bit sdram, a 32-bit region can be defined by the s32sr register. there is an issue with the calculation that is performed to determine whether a transaction is in the 32-bit window or not. the mcu address decoder is missing the msb for the 32-bit region hit/miss. this issue only applies to systems that intend to use the 32-bit re gion. there are no other base address restrictions. implication: 32-bit addresses can be decoded im properly causing unstable code execution. workaround: do not allow the base address, defined by sdbr, to be aligned on an odd 1g boundary (e.g., bit 30 cannot be set to a ?1?: for example, allowable base addresses: 0x8000_0000, 0xa000_0000, 0x2000_0000 non-allowable base addresses: 0x4000_0000, 0xc000_0000, 0x4100_0000 status: fixed. fixed in b-0. see the table , ?summary table of changes? on page 9 . 16. s_gnt[3:2]# outputs are not pulled high when bridge is disabled. problem: when the bridge is disabled (brg_en = 0), the s_gnt[3:2]# signals float (z). these signals need to not float, but be pulled high (h). implication: no negative impact expected. workaround: external pull-ups are required. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 17. split transaction commitment limit register mechanism, in the pci-x bridge, does not operate as implied by the pci-x addendum to the pci local bus specification, revision 1.0a problem: the pci-x addendum to the pci local bus specification, revision 1.0a requires that the bridge operate in a fully buffered mode. the 80331 bridge allows software to write the split transaction limit register, to allow compatibility with existing software, however, it behaves as though the register is programmed with a value ffffh. the bridge forwards all split transactions without regard to the sequence size or the amount of available buffer space. implication: this behavior could result in the bridge split completion buffers becoming full, while additional split completions are being received. when this situation occurs, the bridge either issues a retry or disconnects on the next adb, until buffer space is available. workaround: no workaround. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 .
specification update 23 intel ? 80331 i/o processor non-core errata 18. watchdog time-outs by the pci-x bridge may cause data corruption problem: a watchdog time-out by the pci-x bridge may cause data loss or corruption in an unrelated transaction. implication: watchdog time-outs can cause data corruption. workaround: do not enable the watchdog time-out counter (default setting). the watchdog timer has been de-featured from the 80331. see specification change # 4 . status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 19. discard timer expiration on delayed read can cause data corruption or deadlock when data is still being received on target bus problem: the discard timer in the pci-x bridge starts counting when read data is first received. when data comes in very slowly (for example, when the targ et bus speed is much slower than the requesting bus) the discard timer on the requesting bus may elap se before the read data is complete, and cause state machine errors. implication: when a delayed read in pci-to-pci or pci-to-pcix mode receives immediate data on the destination bus, and the time required to receive that data exceeds the value of the discard timer, data corruption or deadlock may occur. workaround: set discard time-out value to 2^15 (default settin g) or reduce prefetch settings when bus speeds are very different. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 20. configuration cycle attribute parity error signaled incorrectly by pci-x bridge problem: a configuration cycle with an attribute parity error gets a retry response by the pci-x bridge, instead of a target abort. implication: when the serr# enable bit (pcr.8) is not set, transient parity errors may go undetected. workaround: set pcr.8 to enable primary bus serr# assertions for parity error detection. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 21. transactions are buffered during secondary reset problem: when the secondary bus is reset by software (i.e., setting the secondary bus reset bit - bcr.6), the buffer control needs to retry all transactions (ex cept type 0 configuration cycles). the problem is that the buffer controller is not looking at the secondary reset signal, so when the secondary bus reset bit is set (s_rst# asserted) the buffers e nqueue a transaction that was retried. instead, it needs to remain idle until reset is complete, and not enqueue the retried transactions. implication: may cause data corruption. workaround: after de-asserting s_rst# by clearing (i.e., writing a '0') the secondary bus reset bit (bcr.6), wait 155 s before sending a new transaction to the bridge. status: fixed. fixed in c-0 stepping. see the table , ?summary table of changes? on page 9 .
24 specification update intel ? 80331 i/o processor non-core errata 22. primary bus pin mode behavior incorrect during reset in the 80331 no bridge mode problem: in the 80331 no bridge mode (brg_en = 0), several unused primary pci signals provide the wrong behavior during reset. the following signa ls float (?z? = output disabled) during reset: p_ad[63:0], p_par, p_par64, p_c/be[7:0]#. implication: no negative impact expected. workaround: no workaround. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . these signals are ?h? (pulled up to vcc). 23. p_req# pin mode behavior when in the 80331 no bridge mode problem: in the 80331 no bridge mode (brg_en = 0), p_req# (ball t6) drives a 1 in a-1, needs to be ?h? (pulled up to vcc). implication: no negative impact expected. workaround: no workaround. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . note: p_gnt# and p_req# signals have new ball lo cations on b-0, see specification change # 5 . 24. master abort after data transfer within a single adb on pci-x to pci-x read block transactions may cause data corruption or deadlock problem: when a pci-x to pci-x memory read block request is terminated with a single data phase disconnect (sdpd) by the target after the target has provided some data, and a subsequent request in the same allowable disconnect boundary (adb ) is not claimed (master abort), the bridge may deallocate memory buffers not involved in the transaction. implication: this may cause data corruption of another transaction or result in deadlock. this erratum only occurs in pci-x to pci-x mode, the read byte c ount must be greater than 4 bytes and must not cross an adb boundary. the target must respond with a single data phase disconnect and when the bridge attempts to get the remainder of the data, the target does not claim the transaction. workaround: no workaround. the likelihood of this occurrence is extremely small and would require 'bad' behavior by the target. status: fixed. fixed in c-0 stepping. see the table , ?summary table of changes? on page 9 .
specification update 25 intel ? 80331 i/o processor non-core errata 25. boundary scan multi-chip module implementation problem: the 80331 is not bsdl-compliant for the sample and bypass instructions specified by the jtag specification 1149.1. it is compliant for most board-level testing. when boards are tested for opens and shorts, the 80331 bsdl can define the boundary scan length as +1 to encompass the bypass register in the intel xscale ? core (therefore not visible). implication: when doing id, sample, or bypass, the intel xscale ? core bypass register makes the path from tdi to tdo one flop longer than the sp ecification requires, which could cause canned software to error. note: when neither of these are used by the board vendors during manufacturing testing, there is no issue. workaround: intel can provide two bsdl files which allow op ens and shorts testing, as long as it does not test the id and bypass instructions. one covers the intel xscale ? core unit and the other one for the i/o processor, with the exception that both instruct ion sets are reduced from 14 to 7, since they are operating independently. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 26. auto refresh command also generates a precharge all command on ddr bus problem: when an auto refresh command is issued to the mcu sdram initialization register (write 0x6 to sdir) the hardware state machine executes a pr echarge all command and then an auto refresh command. implication: some dimms may fail to initialize. workaround: there is no way to decouple the precharge all and auto refresh commands in the mcu. however, the dcal can issue an auto refre sh command, which can be used in stead to issue the auto refresh for initialization. for both ddri and ddrii initialization sequences, there are two back-to-back autorefresh (arf) commands issued to the dimm (accomplished by writing 0x6 to mcu_sdir 0xffff_e500 twice). this sequence is replaced by writing to the dcal control and status register (dcalsr) 0xffff_f500 to issue an autorefresh to each chip select, thus there are four writes to the dcalsr as opposed to the previo us two writes to mcu_sdir. the exact address and data values are as follows: address write_data note 0xffff_f500 0x8000_0001 -- arf to cs[0] 0xffff_f500 0x8000_0001 -- arf to cs[0] 0xffff_f500 0x8010_0001 -- arf to cs[1] 0xffff_f500 0x8010_0001 -- arf to cs[1] status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 .
26 specification update intel ? 80331 i/o processor non-core errata 27. serr# set to incorrect voltage problem: serr# is being driven to 1 v. the 80331 might detect serr# being asserted during boot-up and does not detect serr# assertion when a device on the pci-x bus asserts serr#. implication: the 80331 falsely detects and logs serr# assertion during boot-up, due to the serr# pin being held at 1 v, which the 80331 detects as a logi c low (asserted). devices assert serr# for a minimum of one clock when an serr# occurs. since serr# is being held low, devices asserting serr# are not detected by the 80331. workaround: putting a 34?39 ? pull-up resistor on serr# might work; however, some add-in cards do not have the drive strength to pull-down against this pull-up, and therefore cannot reliably generate serr# in the system. an alternative workaround is to have software mask serr# assertion in the atu or bridge. status: fixed . fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 28. m66en set to incorrect voltage problem: the m66en signals do not get set to the appropriate level with or without an add-in card present. m66en should be at 3.3 v without an add-in card present. implication: prevents auto-detection of 66 mhz pci de vices. forces the bus speed to 33 mhz when not in pci-x mode and only impacts busses that should be set to 66 mhz pci. workaround: use a 34-39 ohm pull-up resistor on the m66en signals. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 29. p_int[d:a]# not operating correctly problem: the p_int[d:a]# signals only rise to ~1 v at power-on. implication: p_int[d:a]# interrupt signals can cause false interrupts to the host. workaround: use a 34-39 ohm pull-up resistor on the p_int[d:a]# signals. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 30. secondary bus may not initialize correctly at 100 mhz pci-x or 133 mhz pci-x problem: when a 133 mhz pci-x capable device is plugged into the secondary pci-x bus supporting >= 100 mhz pci-x, the 80331 might not correctly initialize the bus at 100 mhz pci-x or 133 mhz pci-x. implication: the bus may initialize at 66 mhz pci-x. workaround: replace the 3.3 kohm pull-up resistor on s_pcixcap with a 1.5 kohm resistor. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 . 31. coalesced writes to 32-bit memory can cause data corruption problem: the bus interface unit (biu) can cause data corruption within the memo ry controller unit when either an 8-byte write with a starting address offset of four (i.e., dword alignment) or a 12-byte write is done to 32-bit memory (or the 32-bit memory region). implication: can cause data corruption. this is not an issue with 64-bit memory subsystems. workaround: when the use of 32-bit memory or the 32-bit memory region is required, write coalescing must be turned off. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 .
specification update 27 intel ? 80331 i/o processor non-core errata 32. atu passing rules operation in pci mode problem: when the secondary pci bus is in pci bus mode, the pci passing rule enforcement logic within the atu, allows a read completion to pass write data; until at least four inbound delayed reads, inbound configuration writes, inbound configuration reads, or any combination of these have occurred from the pci bus. implication: this issue causes a deadlock condition in legacy devices, which contain shared read and write data queues, where the device allocates the data buffer for the requested delayed read data and is also being addressed by the outbound atu write data. this atu functionality does not exist in pci-x mode. workaround: use the secondary pci bus in pci-x mode. when the secondary pci bus is in pci mode, config uration retry is enabled, and the legacy buffer allocating device is present in the system, the atu must not issue writes to that device until the configuration cycles or reads have completed. wh en this situation cannot be achieved by the host, the atu can be momentarily programmed in loopback mode and issue delayed reads to itself. this workaround is only required when the atu is sendin g upstream traffic at the same time as the host is configuring it. this should not happen since the atu needs to wait for the driver to be enabled after enumeration completes. this erratum does not occur when configuration retr y is deasserted at power on and the host meets the above configuration cycles. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 33. s_int[d:a]# pull-ups disabled by internal bus reset problem: during power-on or anytime the internal bus is reset, the s_int[d:a]# interrupt inputs are asserted as the on-die termination (odt) gets disabled. implication: this situation causes floating/asserted interrupts to the 80331, during power-on or anytime the internal bus is reset. workaround: need external pull-ups on the s_int[d:a]# pins. status: fixed. fixed in c-0 stepping. see the table , ?summary table of changes? on page 9 . 34. mcu preemption control does not properly manage the byte count problem: during a transfer, the mcu tracks the byte coun t to determine when a tr ansfer can be preempted. when preemption is enabled, a preempted transfer that is re sumed does not transfer the full remaining byte count of data. implication: can cause data corruption when preemption control is enabled. workaround: do not enable preemption control. keep the default setting of the mcu preemption control register (mpcr, ffff e540h) bits 3-0 as 0h. status: fixed. fixed in c-0 stepping. see the table , ?summary table of changes? on page 9 .
28 specification update intel ? 80331 i/o processor non-core errata 35. i 2 c unit hang condition problem: when a processor reset occurs, the 80331 does not properly detect an idle condition on the i 2 c bus, potentially causing the i 2 c unit to hang indefinitely. this occurs only when an i 2 c slave device is writing a 0 on the sda signal when reset is asserted. the scl signal goes high, but sda remains low, signaling that the bus is still busy. warm reset does not clear up this condition; only a cold reset (power-on) resolves the i 2 c bus hang. implication: the i 2 c bus stays in a hang condition indefinitely workaround: since this is fixed in the c-0 stepping, this workaround must be implemented only when i 2 c hang issues are preventing proper usage of a-2 and b-0 parts. the recommended workaround for a-1 and b-0 parts involves both a hardware and software change. in hardware, tie gpio pins to the scl signals; then in the initialization software, the gpio pins must toggle the scl signals to bring the slave i 2 c devices out of the locked condition. this can be done by using one gpio signal and an external tristate buffer on scl lines, or by using two gpio signals and no external logic to allow unlocking the i 2 c bus. also, the external pwrdelay circuit must use s_rst#, instead of pwrgd. status: fixed. fixed in c-0 stepping. see the table , ?summary table of changes? on page 9 . in the c-0 stepping, the i 2 c bus lock condition can be cleared by software doing a toggle of the gpod[11:10] to toggle scl[1:0]. bit[11] and bit[10] of the gpod register are writable. when gpod[11] is high, scl[1] is driven low. when gpod[10] is driven high, scl[0] is driven low. i 2 c is no longer in the processor reset equation for the internal bus (that it, mrst), so the i 2 c bus can hang when a reset happens during the reading of a 0 from an external i 2 c slave. therefore, the software is required to toggle the i 2 c clock signals (at least eight times) before i 2 c is enabled. gpod bit[11] and bit[10] can be used to unhang the bus by creating a 100 k (5 ms high and low time) or 400 k (1.25 ms high and low time) clock pulse. also, since the i 2 c bus has been removed from the processor reset equation, the pwrdelay circuit is no longer needed. only a 1.5 k ? pull-up to 3.3 v is required on pwrdelay. see specification change 11 , ?pwrdelay needs only a pull-up for battery back-up mode? on page 48 . 36. vpd data register bit 19 is not read/write problem: vpd (vital product data) is an extended capability of the atu. bit 19 of the vpd data register (ffff_e1bch) was implemented as rc (read clear) instead of rw (read/write). implication: this is application dependant as vpd provides the system with information that uniquely identifies hardware and, potentially, software elements of a system. workaround: when the vpd feature is needed, care must be taken to mask bit 19. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 .
specification update 29 intel ? 80331 i/o processor non-core errata 37. intel xscale ? core lockup condition problem: the intel xscale ? core fetches code and data through an internal switch called the bus interface unit (biu), which manages traffic in two directions; a general path to the flash and pci-x interfaces (as well as internal units) and a private path to ddr memory controller. there is a boundary condition for returning data, specifically for code fetches from flash or host memory colliding with private ddr read data. at the wrong clock alignment, the biu corrupts the returning code with the ddr data. this results in arbitrary code returned to the core, resulting in lockup or other unpredictable core behavior. the following describes one scenario of how this condition can occur: ? the intel xscale ? core fetches an instruction cache line, which is executed through the internal bus to the flash interface unit and out to flash memory. ? while this is happening, the intel xscale ? core is scrubbing the ddr clean with a series of data transactions through a second private path, directly to the ddr memory controller. these data transactions are a series of cache line writes to ddr and reads from ddr. ? the original instruction fetch is returned from the flash interface unit back to the core with the critical instruction first (critical word first). ? one clock after the instruction cache line is being returned to the intel xscale ? core , one of the data transactions returns from the ddr memory controller. ? the biu switches to handle the higher priority ddr return. ? the instruction cache line that was being return ed from the flash interface is only partially returned to the intel xscale ? core (five of the eight instructions). ? the data cache line from the ddr memory contro ller is then returned to the intel xscale ? core in its entirety. ? the intel xscale ? core then starts executi ng the instructions that were fetched in the cache line (since the critical instruction was re turned first, the core can continue). ? the five instructions that were re turned are executed by the intel xscale ? core and the core then stalls waiting for the sixth, seventh and eighth instruction to be returned from the initial cache line fill. ? the biu continues to return any outstanding tr ansactions unaware that the instruction cache fetch was not fully returned. note: 1) the case where this happens is where the core memory port is enabled and there is a cache line fill (instruction or data) that executes through the internal bus (flash/pci/etc., transactions, not ddr transactions) and any size fetch to ddr thro ugh the direct port to ddr memory controller. the timing has to be such that the cache line fill fr om the internal bus must beat the ddr return by 1 clock cycle. 2) the scenario given above is just one example of what excites this condition and is by no means the only scenario that excites this condition. implication: this results in a lockup or other unpredictable core behavior. workaround: for a-x and b-0 silicon the only reliable workaround is for software to turn off the core to the ddr memory controller port, redirecting ddr accesses through the internal bus interface with other transactions. this prevents the core lo ckup condition but at a cost to performance. status: fixed. fixed in c-0 stepping. see the table , ?summary table of changes? on page 9 .
30 specification update intel ? 80331 i/o processor non-core errata 38. 32-bit region write corrupts ecc immediately after 64-bit read-modify-write problem: ecc can be corrupted when the following scenario occurs: ? all of memory is initialized to 0s ? a 32-bit region is enabled. ? agent a fills the 64-bit memory region with pattern a. ? agent a does a ddr write to same 64-bit me mory region, causing an read-modify-write (rmw) at the end of the transfer where pattern a is returned as part of the rmw process. ? immediately thereafter, agent b does a ddr write to an open region of 32-bit memory. on dq[63:32] data is driven to pattern a. the wrong ecc is generated (where the ecc is that of dq[63:0] where pattern a is present at the upper half of the bus). implication: the wrong ecc is generated (where the ecc is that of dq[63:0] where pattern a is present at the upper half of the bus). workaround: turn ecc off or don?t use the 32-bit memory region. status: fixed. fixed in c-0 stepping. see the table , ?summary table of changes? on page 9 . 39. reset straps incorrectly sampled on the secondary reset problem: all reset straps are sampled on the rising edge of p_rst#, except the following: memtype, p_boot16# and core_rst#. implication: when external circuitry is used to dynamically control the reset straps, the timing may cause incorrect values to be latched. workaround: by default all reset straps have internal pull-ups. when non-default state is required, then an external 1.5k pull-down resistor should be used. this implementation has no timing requirements. otherwise, when external circuitry is used to dyna mically control, then make sure the proper level is provided at the rising edge of s_rst#. status: fixed. fixed in b-0 stepping. see the table , ?summary table of changes? on page 9 .
specification update 31 intel ? 80331 i/o processor non-core errata 40. pci-x to pci memory read double-word near 1mb boundary may cause the system to hang problem: pci-x to pci memory read dword near a 1 mb boundary may cause the system to hang. implication: in the following scenario: ? a master on the pci-x bus initiates a memory read dword through the bridge, with a starting address that is not dw aligned and is within the last 4 bytes of a 1 mb address boundary. ? on the pci side, the bridge initiates the request and disconnects after a single data phase. the transaction should end at this point, but instead , the transaction is then issued a second time with the starting address at the 1 mb boundary before being retired. ? back on the pci-x side, the completion is issued with the correct data for the initial 4-byte request, followed by a second ?unexpected? comp letion. as a result of the second completion, the internal resource counter gets decremented twice, causing the resource checking logic to assume there is no more room on the chip for split transactions. ? at this point the bridge can no longer process upstream non-posted requests and terminates them with retry. note: the above failure only occurs on a memory read dword from pci-x to pci when the starting address is not dw aligned. a memory read dword to 0xffffc does not fail, whereas a read to 0xfffff does fail. workaround: this issue only affects pci-x to pci tran sactions. pci to pci-x, pci to pci and pci-x to pci-x transactions are not affected. pci-x to pci im plementations should not attempt to do a memory read dword that is not dw aligned and is within the last 4 bytes of a 1 mb address boundary. status: fixed. fixed in c-0 stepping. see the table , ?summary table of changes? on page 9 . 41. pci-x to pci memory read block across 1mb boundary may cause data corruption problem: pci-x to pci memory read block across 1mb boundary may cause data corruption. implication: in the following scenario: ? a master on the pci-x bus initiates a memory read block through the bridge, with a starting address + byte count that crosses a 1 mb boundary. the request is not dword aligned and starts less than three data phases from the 1 mb boundary. ? on the pci side, the bridge initiates the request by setting the low two address bits to 00b as required by the pci local bus specification , revision 2.3. ? the bridge receives data up to the boundary and disconnects, then requests the remainder of the data in a second transaction. ? on the source bus, the bridge should deliver a small completion up to the 1mb boundary with the bcm bit set. however, in this case the bridge plays the request without bcm and uses the full remaining byte count. since the bridge can not disconnect, it winds up satisfying the byte count with garbage for data after the boundary. note: for failure to occur, starting address and byte c ount must be set so the request crosses the 1 mb boundary, but bytes requested after the boundary are less than 4 bytes. requests that are dword aligned do not fail, nor do requests that do not cross the 1mb boundary (even when not aligned). workaround: this issue only affects pci-x to pci tran sactions. pci to pci-x, pci to pci and pci-x to pci-x transactions are not affected. pci-x to pci im plementations that do not cross a 1 mb boundary does not experience this issue. status: fixed. fixed in c-0 stepping. see the table , ?summary table of changes? on page 9 .
32 specification update intel ? 80331 i/o processor non-core errata 42. dma crc result is byte reversed problem: the dma crc result value is byte reversed. example crc operation with the dma: crc seed: 0x0000 0000 data pattern (16 bytes): 0x1234 5678, 0x1457 9098, 0x1234 5678 0x1457 9098 expected crc value: 0x6791 25da actual crc value: 0xda25 9167 crc seed: 0x1122 3344 data pattern(16 bytes): 0x1234 5678 0x1457 9098, 0x1234 5678 0x1457 9098 expected crc value: 0x1d2c b941 actual crc value: 0x41b9 2c1d implication: data corruption occurs when software does not take care of the byte reversal. workaround: software must byte reverse the crc result after the dma completes. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 43. crc corruption on pci-to-local dma transfers problem: crc corruption can occur when polling dma registers during pci-to-local transfers. crc corruption happens regardless of whether the transfer data is written to memory (dma transfer disable bit dcr.7, is set). both dma channels are affected. implication: crc data corruption occurs. the dma tr ansfer itself is not affected by this erratum. workaround: use local address sour ces only when calculating crc. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 44. byte count modified bit set to 1 problem: during a memory read dword which crosses the 1 mb boundary in pci-x to pci mode, the split completion has the correct data and byte count but the bcm (byte count modified) bit in the attribute field is set to 1. in the pci-x addendum to the pci local bus specification, revision 1.0a description of the bcm bit it states, ?bcm is used only for split completions resulting from burst transaction and is set to 0 for split completions resulting from all other commands.? implication: the pci-x addendum to the pci local bus specification, revision 1.0a states that for non-burst transactions that the bcm bit is not to be used and should read 0, this bit is used for diagnostic purposes, and targets (bridges and requesters) are permitted to ignore this bit. workaround: bcm is a non-error status bit, only used for ?flow control? in split completions and should be ignored. status: fixed. fixed in d-0 stepping. see the table , ?summary table of changes? on page 9 .
specification update 33 intel ? 80331 i/o processor non-core errata 45. corrupted byte count and data when crossing 1 mbyte boundary in pci-x to pci mode problem: scenario - memory read block pci-x to pci mode beginning at address 9, 10 or 11 bytes from the 1 mb boundary, with a byte count that crosses the boundary. in this failing scenario, the check for two dwor ds away from the boundary relies on the aligned dword address of the third dword. since the starting address is in the middle of the third dword, the case is missed. the result is the pci read sa tisfies the byte count by reading across the 1 mb boundary. the first split completion on the pci-x bus is correct data, modified byte count and bcm set. the second split completion on the pci-x bus has a corr upted byte count, therefore, the correct data is sent and additional garbage data is then sent until the corrupt byte count is satisfied. the corrupted byte count is a result of crossing the 1 mb boundary. the original byte count minus the byte count captured is less than zero. the failing case is very similar to the previous memory read block case, but the impact to the requester is different. implication: corrupted byte count and additional garbage data is sent to the requester to satisfy the corrupted byte count. in some cases, other transactions (on the bridge) following the bad split completion can be corrupted. when the bridge completes sending the corrupted byte count, it frees the buffer space used by that data. that buffer may contain data for other transactions and that data is lost. workaround: do not allow pci-x to pci memory reads with dword unaligned starting address to cross the 1 mbyte boundary. the starting address must have bits [1:0] equal to 01, 10 or 11 for this erratum to occur. when the starting address[1:0] = 00, this erratum does not occur. status: fixed. fixed in d-0 stepping. see the table , ?summary table of changes? on page 9 . 46. pci-x to pci memory read with 4 k byte count and unaligned starting address problem: the initiator on the pci-x side issues a memory read block with 4 k request byte count (bc=000h), which the bridge terminates with split response. the address in this case is not dword aligned (a[1:0] does not = 00b). on the pc i side, the bridge executes the transaction as memory read multiple, but disconnects after only a single dataphase and does not re-issue the transaction. no split completion is returned to the pci-x bus and the transaction permanently consumes transaction resources. implication: this can perman ently consume transaction resources, and th erefore could result in a system hang. workaround: use addresses that are dword aligned or any byte count other than 4 k. status: fixed. fixed in d-0 stepping. see the table , ?summary table of changes? on page 9
34 specification update intel ? 80331 i/o processor non-core errata 47. vccddr (vcc25/vcc18) current spike problem: an internal ddr signal gets routed through logic that is powered by the vcc15 rail. this signal gets driven to the wrong level when vcc15 rail is not powered up. this signal controls the input and output enable of all ddr buffers, so when vcc15 is off and vcc25/18 is on, it asserts high and cannot tristate the ddr outputs. the issue can occur at power-up, power down and power fail when battery back-up continues to power the 80331. implication: excessive vcc25/18 power supply rail current to the vss rail is experienced until vcc15 core supply is up. also, when using ddr-i mode (vcc25), the buffers can be overstressed when vcc15 = off and vcc25 = on. this can cause a reliability problem since the processor may become damaged over time. when in ddr-ii mode (vcc18), the buffers do not overstress since vcc18 maximum is 1.9 v. therefore, no reliability problems exist. workaround: a new power sequencing requirement should be followed for b-0 and c-0 steppings. this problem does not affect a-1 stepping, and is being fixed in c-1 stepping. 1. vcc33 power up 2. vcc15 power up 3. vcc25/18 power up the vcc15 minimum supply voltage has to be within 25% of the vcc25 supply voltage, until the vcc15 supply reaches 1.425 v (vcc15 minimum), during power-up and power-down sequences. this is the minimum requirement to ensure no gate overstress when using ddr-i memory. for power-fail condition, the battery should power only the dimm. the 80331 should be isolated from the battery power. status: fixed. fixed in c-1 stepping. see the table , ?summary table of changes? on page 9 .
specification update 35 intel ? 80331 i/o processor non-core errata 48. bridge pci ordering rule violation problem: when the bridge is in pci-to-pci mode, it re ceives a downstream memory write which is claimed by the bridge, followed by a subsequent memory read request which is enqueued immediately afterwards. at the same time, the upstream buffers on the chip are filled with upstream memory writes and read completion data. on the destination bus, the memory write is issued in small fragments due to either target disconnect or a low setting of the secondary mlt, and the upstream buffers begin to free up due to delivery of upstream memory write data. in between delivery of downstream memory write fragments, the bridge issues the subsequent memory read, in violation of pci ordering rules. summary of the four failure modes: 1. pci-to-pci: a memory read transaction may pass a previously enqueued memory write. 2. pci-to-pci: a configuration or i/o read transaction may pass a previously enqueued memory write. 3. pci-to-pci: a configuration or i/o write transaction (including type1 configure-to-special cycle) may pass a previous ly enqueued memory write. 4. pci-x-to-pci: a configuration or i/o write tran saction (including type1 configure-to-special cycle) may pass a previous ly enqueued memory write. implication: in the above s cenario, a pci read/write transaction can pass a pci memory write transaction which violates pci ordering rules. when the primary bus is pci and secondary bus is pci-x, this would only be seen as described in item 4 listed above. no impact when the bridge is configured in pci-x to pci-x mode. workaround: use in pci-x to pci-x mode. when the primary bus is pci and secondary bus is pci-x, do not use upstream dword i/o or type1 configure-to-special cycle writes that must be ordered against previously issued memory writes. status: fixed. fixed in d-0 stepping. see the table , ?summary table of changes? on page 9 . 49. atu claims pci commands 8 and 9 when issued as dual address cycle (dac) problem: in pci mode, commands 8 and 9 are reserved. the appropriate pci response to these commands is to master abort. when these commands are issued as a dual address cycle (dac), the address translation unit (atu) claims them and they ar e executed as memory read (command 8) and memory write (command 9) on the internal bus. the atu properly master aborts sac pci commands 8 and 9. this issue does not occur in pci-x mode. implication: no negative imp act expected, since these pci commands are ?reserved? and should not be issued to the atu. workaround: no workaround. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 .
36 specification update intel ? 80331 i/o processor non-core errata 50. secondary bus pci rst# pulse prior to the rising edge of p_rst# problem: during system power on and prior to 80331 receiving the rising edge of p_rst#, a pulse may be observed on the secondary bus pci rst# signal (s_rst#). this functionality is a result of the 3.3v to 1.5v leakage described in specification clarification 19. other signals that may see a pulse during power-on include the following: all peripheral bus interface (pbi), pci, gpio, uart, jtag and pwrdelay signals. refer to specification clarification 23 for specifics on pwrdelay. signals not included are ddr and i2c. implication: pci/pci-x controllers on the secondary bus segment could interpret this s_rst# pulse as a true rising edge and initialize into an undetermined state. pulses on pwe# and pcex# may cause data corruption for memory devices connected to the pbi bus. workaround: a hardware workaround has been identified. the p_rst# signal that is received by the 80331 can be used to gate the secondary bus pci rst# signal. for example, use p_rst# and s_rst# as inputs to an and gate and connect the output to the secondary device rst# pin. the gate delay should be kept down to a couple nanoseconds, so as to not interfere with the pci initialization pattern. another workaround is to bring up 3.3 v and 1.5 v power rails simultaneously, but continue to maintain the power sequencing re quirement (as specified in the design guide) for these two power rails. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 51. slow edge rates observed when 80331 is driving the primary bus problem: signal integrity issues might occur when the 80331 is driving the primary pci/pci-x bus in conventional pci or pci-x modes. implication: parity errors and system hangs may occur. workaround: a software workaround has been identified. the workaround is required for reliable conventional pci and pci-x mode operation. the workaround is to write all 1s to the pci drive strength overrides with the intel xscale ? core. bit 31 should be set in the following two registers to enable drive strength override: ? 3.3 v drive strength control register at ffff_f5d0h ? 1.5 v drive strength control register at ffff_f5d4h the default value is 0000_3f3fh for both registers. status: fixed. fixed in c-0 stepping. see the table , ?summary table of changes? on page 9 .
specification update 37 intel ? 80331 i/o processor non-core errata 52. enabling the core-to-memory port can cause a stall condition problem: a stall condition can occur during high data throughput to the memory controller unit (mcu), due to a non-empty bus interface unit (biu) data queue that might allow no further traffic to be submitted from the intel xscale ? core. the stall is due to an in valid state in the queue control registers and the associated pointers. the pointers and the queue status bits get out of sync, allowing part of the biu to conclude that it is full and therefore not to accept any more transactions. the other part of the biu concludes that it is empty, and therefore does not flush the non-empty condition. the stall condition can be generated in the following scenario: 1. within the mcu, accept a read from one port (core-to-memory or ib-mcu). this triggers an automatic coherency check, which requires write s within the same 1 k address ?page? to be pushed ahead of the read. 2. an ?incoherent? write (in other words, a write that must precede the read from step 1) must exist in the opposite port. this write is executed to ddr memory as normal. 3. a read must also exist in the opposite port; destination (coherent or incoherent) is unimportant. this has the effect of maintaining the port?s request to the mcu. 4. an incoherent write arrives in the original po rt during the exact cycle the opposite write is completed. 5. due to the combination of pending read requ est and last-second incoherent write, the mcu gets out of sync and attempts to acknowledge a write from the wrong port. this causes the offending queue pointer/status bit mismatch. this situation locks the opposite port to the original read transaction. implication: enabling the core-to-memory port (biu cr.0 = 1, ib address = ffff_e608h) can cause a stall condition or data corruption. workaround: do not enable the core-to-memory port in the biu control register (biucr.0). when biucr.0 = 0 (default condition), the core-to-memory port is disabled and forces all intel xscale ? core memory transactions to be issued out the core internal bus (ib) port, therefore avoiding the stall condition. note: disabling the core-to-memory port require s a review of specifi cation clarification 13 , ?bus interface unit follows pci ordering rules? on page 54 . status: fixed. fixed in d-0 stepping. see the table , ?summary table of changes? on page 9 .
38 specification update intel ? 80331 i/o processor non-core errata 53. pci-to-pci read flow-through with destination trdy# stalls can cause data corruption problem: pci-to-pci read flow-through with destination trdy# stalls can cause data corruption. implication: the scenario is a pci-to-pci memory r ead with flow-through enabled (source bus bandwidth is less than or equal to destination bus bandwidth). requestor initiates the read on the source bus, and it is retried by the bridge (executed as a delaye d transaction). the bridge plays the transaction on the destination bus and starts receiving data from the target. after getting two or three cache lines, the transaction is requested again on the source bus, and the bridge enters flow-through. the target device on the destination bus begins to insert target wait-states, and eventua lly ends the transaction by stalling trdy# for a number of clocks then signaling disconnect without data at the cache line boundary. on the source bus, the bridge delivers an extra garbage dataphase beyond what was received on the destination side, causing data corruption. the affected mode is pci-to-pci only. neither pci-x-to-pci-x nor pci-to-pci-x modes allow trdy# stalls on the destination side. workaround: do not use in pci-to-pci configuration. exp ected usage model for the 80331 is that the secondary pci bus operates in pci-x mode only. for an alternate workaround, when in a system that has devices that might terminate transactions in the above manner, the prefetch policy registers must be set so that the target is not given the opportunity to significantly stall trdy#. for example: when a device can provide 256 bytes in a timely manner, but delays a request for 384 bytes, the first read and reread factors must not be set higher than 01h (giving an mrm prefetch of 256 bytes, assuming a 64-byte cache-line size). status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 54. s_pcixcap pci mode threshold is too high problem: the ?pci mode? threshold on the s_pcixcap signal on the secondary pci bus is too high (1.87 v). this has the effect of detecting a pci bus when more than two slots are populated with pci-x 66 cards. implication: a heavily loaded secondary pci bus (three or four slots), might operate in pci mode instead of pci-x mode. workaround: when a board is configured with more than two pci-x slots, a circuit can be added to adjust the pcixcap voltage. status: fixed. fixed in d-0 stepping. see the table , ?summary table of changes? on page 9 .
specification update 39 intel ? 80331 i/o processor non-core errata 55. no support for burst i/o and configuration read/writes problem: the 80331 bridge does not support burst i/o read, i/o write, configuration read, or configuration write in pci mode. implication: in conventional pci mode, it is legal for a requester to attempt a burst i/o read, i/o write, configu- ration read, or configuration write. the 80331 bridge supports only single data phase configuration and i/o transactions. when a master attempts to issue a burst i/o or configuration read, the bridge does not assert stop# after the first data phase, resulting in data corruption of all dwords beyond the first. for burst i/o or configuration writes, the bridge asserts stop#, but does not de-assert trdy# on the final data phase, resulting in loss of data (the second data phase is dropped by the bridge). pci-x does not permit these modes of operation. workaround: x86 processors do not allow this condition to occur. in non-x86 systems that do not preclude these burst mode operations, the application must limi t the transfer to a single aligned dword (32 bit) operation. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 56. read flow through hangs due to disconnect without data at a buffer boundary. problem: read flow through hangs due to disconnect without data at a buffer boundary. implication: in pci to pci mode an upstream read is issued to the bridge and forwarded to the primary bus, using a calculated prefetch size of at least 3 cache lines. on the primary bus, the target claims the request, and delivers data (with intermittent trdy# slips) up to a 128-byte boundary, then deasserts trdy# and waits a number of clocks before disconnecting without data. after the 2nd chatelaine gets on chip, the bridge enters flow-through and begins delivering data to the initiator. if the time difference between the en d of the primary bus read and the end of the secondary bus read is approximately 10 clocks or less, the bridge may hang after the data is delivered. workaround: pci-x to pci-x and pci to pci-x implementations are not affected by this issue. for pci to pci systems in which targets might exhibit the above behavior, set all prefetch factors to 000b. this will set the maximum prefetch size to 2 cachelines (for mrm) and effectively disable read flow-through. there may be a performance impact due to these settings. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 57. p_serr# not asserted for parity error on ad[63:32] problem: primary side p_serr# is not asserted for a parity error on ad[63:32] during the data phase of a split response to a read request issued by the bridge. implication: since no valid data is driven onto the upper a/d bus during a split response for a read transaction, there are no negative side affects of not asserting p_serr# in this case. this behavior does not comply with the pci-x specification v1.0a requirements in section 5.4.1.3, however it will have no impact in the application. workaround: no workaround needed. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 58. bus interface unit (biu) claims dac addresses in the range of the memory mapped registers (mmr problem: the biu incorrectly decodes and claims dual address cycle (dac) addresses in the xxxx_xxxx_ffff_e000h to xxxx_xxxx_ffff_ffffh range (e.g. - ?x? represents any bit being set
40 specification update intel ? 80331 i/o processor non-core errata to ?1?). the 32-bit address range of ffff_e000h to ffff_ffffh on the internal bus, represents mmr and reserved space. when a 64-bit address in this range is presented on the internal bus, multiple internal bus units, one of them being the biu, will claim the transaction. note: only the dma can generate a 64-bit address (dac) on the internal bus. implication: using dac addresses in the xxxx_xxxx_ffff_e000h to xxxx_xxxx_ffff_ffffh range on the internal bus will cause an internal bus conflict that may result in the reception of undesired data and setting of error flags. workaround: avoid using the dma with dac addresses in the xxxx_xxxx_ffff_e000h to xxxx_xxxx_ffff_ffffh range. this can be done by utilizing one of the two 64mb atu outbound memory windows (8000 0000h or 8400 0000h) and its corresponding outbound translation registers (omwtvr0/oumwtr0 or omwtvr1/oumwtr1) in order to present a 32 bit address on the internal bus and generate a 64 bit address on the pci bus. the upper translate value register should be programmed with the upper 32 bits of the desired pci address. the lower translate value register would th en be configured to or in the appropriate value such that the desired lower 32 bits appear on the pci bus after translation. refer to section 3.2.2 ?outbound transactions ? single address cycle (sac) internal bus transactions? in the intel? 80331 i/o processor developer?s manual (274065) for more information on how the windowing and translation scheme works. it is possible to now generate the 32 bit internal bus transaction either using the core or the dma. both options are viable and one may be preferable over the other depending on the application. note: use of the dma to generate the transaction would require not only the modification of the descriptors in question and setting of the memory-memory transfer enable bit (dcrx) for those descriptors, but care must also be taken not to allow any individual transfer to overrun the size of the outbound window (64mb). status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 59. pcix-to-pci memory read issued as 32-bit, then retried as 64-bit problem: a 32-bit memory read transaction from pci-x to pci may be retried with req64# asserted in violation of the pci specification. implication: a memory read with multiple dataphases requested is issued from the pci-x side across the bridge and played on the pci-side of the bridge. this read gets some data and is then disconnected by the target. at the same time, a memory read with star ting address less than 4dw from the next adb is enqueued on the pci-x side and then issued on the pci immediately after the first read is discon- nected. this read is issued the first time with req64# d easserted and is retried by the target (delayed transaction). some time later, the bridge re-issues this read with req64# asserted, violating pci requirements that req64# remain the same for every retry. note: this can only occur in pci-x to pci transactions. this behavior is fairly common in many pci devices and generally has minimal side effects on overall system performance. in some systems, depending on the setting of the discard timer, a delay may occur before normal system throughput is restored. workaround: limit the pci-side to 32-bit only in x-to-i configurations. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 .
specification update 41 intel ? 80331 i/o processor non-core errata 60. tc1(min) of the pci-x clock observed to be marginally less than the requirement specified for the pci-x (mode 1, class1) clock jitter. problem: the 80331 generates the pci-x clock with a nominal frequency of 133 mhz (tc1 of 7.5 ns). after considering the clock jitter, the minimum clock period (tc1(min)) observed at the pin may be less than 7.5 ns. the pci-x class 1 clock jitter specification for mode 1 requires the tcyc-min to be 7.5 ns with jitter consideration. the same applies for the pci-x clock generated @ 66 mhz. implication: no negative impact is expected, when compliant with the routing guidelines. workaround: there is no workaround to adjust the minimum clock period (tc1(min)) of the pci-x clocks. however, the routing guidelines for the pci-x clock signal take into consideration the effect of the jitter on the minimum clock period (tc1(min)). conforming to the routing guidelines in the 80331 design guide will offset the effect of the marg inally reduced minimum clock period (tc1(min)) towards the setup and hold times. therefore, for sy stem boards that are compliant with the routing guidelines, the risk of violating the setup and hold time requirements and any resulting functional impact, is low. please refer to the 80331 i/o processor design guide (273823) for further information on the pci-x clock routing guidelines. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 61. i2c control register reset bit does not function problem: the i2c control register (icr0 and icr1) bit 14 is supposed to be used for resetting the i2c unit, but writing a '1' to this bit does not reset the i2c unit. writing a '1' to bit 14 has no effect. implication: the i2c unit cannot be reset by using icrx.14. workaround: depends on what needs to be accomplished. asserting p_rst# or setting bcr.6 will reset the i2c unit but will also reset the entire chip or the secondary bus/atu. for an i2c bus lock condition, it may be cleared by software doing a toggle of the gpod[11:10] to toggle scl[1:0] (see non-core erratum 35 ). if sda[1:0] need to be toggled, then an external device or unused gpio will need to be used to control this sequence. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 . 62. internal clock misalignment can cause processor hang problem: after a reset, the 80331 can hang during initial accesses to sdram, due to a possible clock misalignment, aggravated by a race condition in the clock divider clear circuit. implication: a failure will manifest itself as a hang of the i/o processor after reset, during initial accesses to sdram. subsequent warm or cold resets may clear the condition and allow the 80331 to continue operation. workaround: in most cases, doing a cold or warm reset will clear this condition. increasing the 1.5v power supply will reduce the probability of a processor hang. intel is screening parts to eliminate the probability of occurrence (refer to specification change #22 ?internal clock misalignment? on page 50 ). status: fixed. this issue was fixed in the d-1 stepping of the product (this is also related to specification change #22 ?internal clock misalignment? on page 50 ). 63. spurious dma0 end-of-transfer interrupt problem: when the interrupt controller goes from having no interrupts asserted to one or more asserted, there is a 1-clock cycle window in which the iintvec (irq interrupt vector register; ffff_e7c8h or cp6, register 14) or fintvec (fiq interrupt v ector register; ffff_e7cch or cp6, register 15) may report the value of the intbase register (interrupt base register; ffff_e7c0h or cp6, register 12), which is the vector address for interrupt 0, dma0 end-of-transfer. this condition can occur even if the dma0 eot interrupt is masked, intctl0.0 = 0.
42 specification update intel ? 80331 i/o processor non-core errata implication: no negative impact expected. if the rou tine that reads the iintvec/fintvec qualifies the return value against iintsrc0.0/fintsrc0.0, it will either see there is nothing to do or it will validly call the dma0 end-of-transfer handler. workaround: if iintvec/fintvec equals intbase, then re-read the iintvec/fintvec register. status: no fix. not to be fixed. see the table , ?summary table of changes? on page 9 .
specification update 43 intel ? 80331 i/o processor core errata core errata 1. abort is missed when lock command is outstanding problem: a bus abort occurs on a code fetch, wh ile an instruction tlb or i-cache lock mcr, move to coprocessor from arm register , command is outstanding. the core fails to abort, instead executing the instruction returned on the aborting transaction. parity errors are not affected. the bus abort may be due to either an abort pin assertion or a multi-bit ecc error. workaround: branch flush after every i-tlb or i-cache lock. for example, the following instruction does this: sub pc, pc #4;flush the pipe. status: no fix. see the table , ?summary table of changes? on page 9 . 2. aborted store that hits the data cache may mark write-back data as dirty problem: when there is an aborted store that hits clean data in the data cache (data in an aligned four word range that has not been modified from the core sin ce it was last loaded in from memory or cleaned), the data in the array is not modified (the store is blocked), but the dirty bit is set. when the line is then aged out of the data cache or explicitly cleaned, the data in that four word range is evicted to external memory, even though it has never been changed. in normal operation this is nothing more than an extra store on the bus that writes the same data to memory that is already there. here is the boundary condition where this might be visible: 1. a cache line is loaded in to the cache at address a. 2. another master externally modifies address a. 3. a core store instruction attempts to modify a, hits the cache, aborts because of mmu permissions, and is backed out of the cache. that line normally is not marked dirty, but because of this errata is marked as dirty. 4. the cache line at a then ages out or is explicitly cleaned. the original data from location a is evicted to external memory, overwriting the data written by the external master. this only happens when software is allowing an external master to modify memory that is, write-back or write-allocate in the core page tables, and depending on the fact that the data is not 'dirty' in the cache, to preclude the cached version from over writing the external memory version. when there are any semaphores or any other handshak ing to prevent collisions on shared memory, this is not a problem. workaround: for this shared memory region, mark it as write-through memory in the core page table. this prevents the data from ever being written out as dirty. status: no fix. see the table , ?summary table of changes? on page 9 .
44 specification update intel ? 80331 i/o processor core errata 3. performance monitor unit event 0x1 can be incremented erroneously by unrelated events event 0x1 in the performance monitor unit (pmu) can be used to count cycles in which the instruction cache cannot deliver an instruction. the only cycles counted should be those due to an instruction cache miss or an instruction tlb miss. the following unrelated events in the core, also causes the corresponding count to increment when event number 0x1 is being monitored: ? any architectural event (e.g., irq, data abort) ? msr instructions which alter the cpsr control bits. ? some branch instructions, including indirect branches and those mispredicted by the btb. ? cp15 mcr instructions to registers 7, 8, 9, or 10 which involve the instruction cache or the instruction tlb. each of the preceding items may cause the perfo rmance monitoring count to increment several times. the resulting performance monitoring count may be higher than expected, when the preceding items occur, but should never be lower than expected. workaround: there is no way to obtain the correct number of cycles stalled due to instruction cache misses and instruction tlb misses. extra counts, due to branch instructions mispredicted by the btb, may be one component of the unwanted count that can be filtered out. the number of mispredicted branches also can be monitored using performance monitoring event 0x6 during the same time period as event 0x1. the mispredicted branch number then can be subtracted from the instruction cache stall number generated by the performance monitor to get a value closer to the correct one. this workaroun d only addresses counts contributed by branches that the btb is able to predict. all the items in the preceding bulleted list still affect the count. depending on the nature of the code being monitored, this workaround may have limited value. status: no fix. see the table , ?summary table of changes? on page 9 . 4. in special debug state, back-to-back memory operations ? where the first instruction aborts ? may cause a hang problem: when back-to-back memory operations occur in the special debug state (sds, used by ice and debug vendors) and the first memory operation gets a precise data abort, the first memory operation is correctly cancelled and no abort occurs. depending on the timing, however, the second memory operation may not work correctly. th e data cache may internally cancel the second operation, but the register file may have scoreboa rded registers for that second memory operation. the effect is that the core may hang (due to a pe rmanently scoreboarded register) or that a store operation may be incorrectly cancelled. workaround: in special debug state, any memory opera tion that may cause a precise data abort should be followed by a write-buffer drain operation. this precludes further memory operations from being in the pipe when the abort occurs. load multiple/store multiple that may cause precise data aborts should not be used. status: no fix. see the table , ?summary table of changes? on page 9 .
specification update 45 intel ? 80331 i/o processor core errata 5. accesses to the cp15 id register with opcode2 > 0b001 returns unpredictable values problem: the arm architecture reference manual (arm ddi 0100e) states the following in chapter b-2, section 2.3: when an value corresponding to an unimplemented or reserved id register is encountered, the system control processor returns th e value of the main id register. id registers other than the main id register are defined so th at when implemented, their value cannot be equal to that of the main id register. software can therefore determine wh ether they exist by reading both the main id register and the desired register an d comparing their values. when the two values are not equal, the desired register exists. the intel xscale ? core does not implement any cp15 id code registers other than the main id register (opcode2 = 0b000) and the cache type register (opcode2 = 0b001). when any of the unimplemented registers are accessed by software (e.g ., mrc p15, 0, r3, c15, c15, 2), the value of the main id register was to be returned. instead, an unpredictable value is returned. workaround: no workaround. status: no fix. see the table , ?summary table of changes? on page 9 . 6. disabling and re-enabling the mmu can hang the core or cause it to execute the wrong code problem: when the mmu is disabled via the cp15 control register (cp15, cr1, opcode_2 = 0, bit 0) after being enabled, certain timing cases can cause the processor to hang. in addition to this, re-enabling the mmu after disabling it can cause the proces sor to fetch and execute code from the wrong physical address. to avoid these issues, the code sequence below must be used whenever disabling the mmu or re-enabling it afterwards. workaround: the following code sequence can be used to disable and/or re-enable the mmu safely. the alignment of the mcr instruction that disables or re-enables the mmu must be controlled carefully, so that it resides in the first wo rd of an instruction cache line. @ the following code sequence takes r0 as a parameter. the value of r0 will be @ written to the cp15 control register to either enable or disable the mmu. mcr p15, 0, r0, c10, c4, 1 @ unlock i-tlb mcr p15, 0, r0, c8, c5, 0 @ invalidate i-tlb mrc p15, 0, r0, c2, c0, 0 @ cpwait mov r0, r0 sub pc, pc, #4 b 1f @ branch to aligned code .align 5 1: mcr p15, 0, r0, c1, c0, 0 @ enable/disable mmu, caches mrc p15, 0, r0, c2, c0, 0 @ cpwait mov r0, r0 sub pc, pc, #4 status: no fix. see the table , ?summary table of changes? on page 9 .
46 specification update intel ? 80331 i/o processor core errata 7. updating the jtag parallel registers requires an extra tck rising edge problem: the ieee 1149.1 spec states that the effects of updating all parallel jtag registers should be seen on the falling edge of tck in the update-dr state. the intel xscale ? core parallel jtag registers, incorrectly require an extra tck rising edge to ma ke the update visible. therefore, operations like hold-reset, jtag break, and vector traps require either an extra tck cycle by going to run-test-idle or by cycling through the state machine again in order to trigger the expected hardware behavior. workaround: when the jtag interface is polled continuous ly, this erratum has no effect. when not, an extra tck cycle can be caused by going to run-test-idle after writing a parallel jtag register. status: no fix. see the table , ?summary table of changes? on page 9 . 8. non-branch instruction in vector table may execute twice after a thumb mode exception problem: when an exception occurs in thumb mode and a non-branch instruction is executed at the corresponding exception vector, that instruction ma y execute twice. typically instructions located at exception vectors must be branch instructions which go to the appropriate handler, but the arm architecture allows the fiq handler to be placed directly at the fiq vector (0x0000001c/0xffff001c) without requiring a branch. because of this bug, the first instruction of such an fiq handler may be executed twi ce when it is not a br anch instruction. workaround: when a ?nop? is placed at the beginning of the fiq handle r, the ?nop? executes twice and no incorrect behavior results. when a branch instruct ion is placed at the beginning of the handler, it does not executed twice. status: no fix. see the table , ?summary table of changes? on page 9 .
specification update 47 intel ? 80331 i/o processor specification changes specification changes 1. hpi# (high priority interrupt) is a maskable interrupt issue: the hpi# interrupt input is both maskable and masked by default (as are all interrupts). it is controlled by intctl1.31. hpi# operates the same as the other external interrupt inputs (s_int[d:a]#). 2. pciodt_en reset strap signal issue: pci bus odt enable (pciodt_en) is a reset strap muxed onto signal a[20] and is latched on the rising (de-asserting) edge of p_rst#. it is used to determine when the secondary pci(-x) bus uses internal pull-ups on the following signals: s_ad[63:32], s_c/be[7:4]#, s_par64, s_req64#, s_req[3:0]#, s_ack64#, s_frame#, s_irdy#, s_devsel#, s_trdy#, s_stop#, s_perr#, s_lock#, s_m66en, s_serr# and s_int[d:a]#. when disabled, then external pull-up resistors ar e required. pci odt enable is valid for the 80331 secondary pci bus only. secondary pci bus options: 1. pciodten = 1 (default), enables 8.2 k internal pull-ups to 3.3 v. 2. pciodten = 0, external 8.2 k pull-ups to 3.3 v are required. 3. lock# functionality has been de-featured issue: the lock# functionality of the pci-x bridge has been de-featured from the 80331. 4. watchdog timer and retry timer has been de-featured issue: the watchdog timer and retry timer of the pci-x bridge has been de-featured from the 80331. 5. p_gnt# and p_req# signals have new ball locations on b-0 issue: the location of p_req# and p_gnt# on a-1 causes a violation of the maximum trace length required by the pci local bus specification , revision 2.3: p_req# signal is moving from t6 on a-1 to h11 on b-0. p_gnt# signal is moving from r4 on a-1 to g12 on b-0. the 80331 boards need to incorporate series resistors that can be populated/de-populated for connection to either the a-1 or b-0 p_req#/p_gnt# ball location. route the p_req# net to the two ball locations as separate routes through two 0 ohm series resistor located near the pci edge connector. route the p_gnt# net to the two ball locations as separate routes through two 0 ohm series resistor located near the pci edge connector . populate the resistor that connects the net to the correct ball according to the silicon revision. 6. peripheral performance monitor unit has been de-featured issue: the peripheral performance monitor unit has been de-featured. the intel xscale ? core pmon is still functional.
48 specification update intel ? 80331 i/o processor specification changes 7. processor device id has been removed issue: the processor device id (pdir) at ffff e780h is suppose to mirror the jtag id, but instead has a value of 0x0. this register is not to be fixed in future steppings, since there are other registers that can be read to determine processor type and revision information. 8. 1.5k pull-down required on ad[15] of the pbi bus issue: in order to prevent secondary pci clock instabilities, make sure ad[15] of the pbi bus has a 1.5 k pull-down. 9. ocd and receive enable calibration de-featured issue: the ability to adju st the electrical interface to account for out of specification ddr-ii dimms using ocd (off-chip driver) and receive enable calibration, is no longer a supported feature. 10. new watchdog timer (wdt) functionality in b-0 stepping issue: watchdog timer (wdt) expiration can either generate a chip reset or a core interrupt. added watchdog timer interrupt control to the following register bits: intctl0.17, intstr0.17, iintsrc0.17, fintsrc0.17, ipr1.3:2 control for wdt reset or interrupt generation is done by the interrupt mask bit, intctl0.17. when clear (default), the wdt generates a reset. when set, the wdt generates an interrupt to the core. these functions are mutually exclusive. the wdt is disabled by default see the developers manual for the enabling sequence. 11. pwrdelay needs only a pull-up for battery back-up mode issue: the i 2 c bus has been removed from the processor reset equation (see erratum # 35 ). this allows the pwrdelay circuit to be simplified to a single pull-up resistor, to enable battery back-up mode. pwrdelay must be isolated from all other circuitry, and only a 1.5k pull-up to 3.3 v is required. when battery back-up is not required, pwrdelay should have a 1.5 k pull-down resistor. note: in some applications pwrdelay may control other board logic. before making this change, make sure the other logic is not adversely impacted. 12. arb_en signal has been de-featured issue: the arb_en reset strap, muxed on ad[1], has been de-featured from the 80331. when using ?no bridge? mode (brg_en=0), arb_en needs to be pulled low. 13. intel? 80331 i/o processor design guide change for unbuffered ddr-i dual-banked dimms issue: the latest routing guidelines for unbuffered ddr-i dual-banked dimms are available upon request and is included in the next revision of the design guide. update - these routing guidelines were added to the october 2004 release of the 80331 design guide (273823-002) 14. ddrres2 can be pulled down to reduce current during self-refresh issue: ddrres2 is used as compensation for ddr-ii ocd. since ocd is not supported in the 80331 (see specification change # 9 ), then ddrres2 can be pulled do wn to reduce current draw during self-refresh mode. 15. intel? 80331 i/o processor design guide change for peripheral bus interface (pbi) issue: the latest routing guidelines for the peripheral bus interface (pbi) are available upon request and included in the next revision of the intel ? 80331 i/o processor design guide .
specification update 49 intel ? 80331 i/o processor specification changes update - these routing guidelines were added to the october 2004 release of the 80331 design guide (273823-002) 16. intel? 80331 i/o processor design guide change for pci/-x busses issue: the latest routing guidelines for the pci/-x bu sses are available upon request and included in the next revision of the intel ? 80331 i/o processor design guide . update - these routing guidelines were added to the october 2004 release of the 80331 design guide (273823-002) 17. internal bus operates at 333 mhz for d-0 stepping issue: for the d-0 stepping of the 80331, the internal bus operates at 333 mhz. for all previous steppings, the internal bus runs at 266 mhz. 18. application accelerator unit enhanced for d-0 stepping issue: the application accelerator unit (aau) in the d-0 stepping ha s been enhanced to support raid 6 functionality. the details of this new feature are described in an addendum to the aau chapter. 19. recommended dll register values issue: using the default dll values in combination with low duty cycle dimms may result in low hold time margins on read transactions. the default values for the dll master and slav e registers do not center the internal dqs with respect to the eye of the incoming data. using the default values may result in a reduced hold time due to dqs being late in the data eye, which could lead to ecc errors. errors have only been observed when using dimms that have a low dqs duty cycle. note: all of the intel validation up to this point has been with the default, worst case dll values and all dimms used in validation have passed. firmware should be updated and tested with these new dll values, in order to add margin to the hold timing during memory reads. ddr-ii 400 settings slvlmix0 - address ffff_f554h; recommended value - 3333_3333h slvlmix1 - address ffff_f558h; recommended value - 0000_0003h slvhmix0 - address ffff_f55ch; recommended value - 3333_3333h slvhmix1 - address ffff_f560h; recommended value - 0000_0003h slvlen - address ffff_f564h; recommended value - 0000_0003h mastmix - address ffff_f568h; recommended value - 0000_000ah mastlen - address ffff_f56ch; recommended value - 0000_0002h ddr-i 333 settings slvlmix0 - address ffff_f554h; recommended value - 6666_6666h slvlmix1 - address ffff_f558h; recommended value - 0000_0006h slvhmix0 - address ffff_f55ch; recommended value - 6666_6666h slvhmix1 - address ffff_f560h; recommended value - 0000_0006h slvlen - address ffff_f564h; recommended value - 0000_0003h mastmix - address ffff_f568h; recommended value - 0000_0000h mastlen - address ffff_f56ch; recommended value - 0000_0002h 20. ddr-ii jedec initialization sequence includes writes to emrs2 and emrs3 issue: the jedec ddr-ii specification includes a write to emrs2 and emrs3 (extended mode register set) during the initialization sequence. step 5 is ?issue emrs2 command? and step 6 is
50 specification update intel ? 80331 i/o processor specification changes ?issue emrs3 command?. in order to be jedec compliant, these steps should be added to the memory controller initialization sequence. note: before implementing, check with your dimm/memory manufacturer to determine if these steps are necessary. software should always follow the initialization sequence provided by the dimm/memory manufacturer guidelines. the following pseudo code shows the emrs initialization steps that are required to be compliant with the jedec ddr-ii initialization sequence. // step 5 and 6 - emrs(2) and emrs(3) programming if memorytype is ddr-ii write 0x2 to dcaladdr (setting ba[1:0] for emrs(2)) write 0x81000003 to dcalcsr (issue emrs command to cs0) wait for dcalcsr[31] to report ?operation completed? write 0x81100003 to dcalcsr (issue emrs command to cs1) wait for dcalcsr[31] to report ?operation completed? write 0x3 to dcaladdr (setting ba[1:0] for emrs(3)) write 0x81000003 to dcalcsr (issue emrs command to cs0) wait for dcalcsr[31] to report ?operation completed? write 0x81100003 to dcalcsr (issue emrs command to cs1) wait for dcalcsr[31] to report ?operation completed? endif 21. case temperature (tcase) change issue: to be consistent with the production test en vironment, the case temperature (tcase) for the 80331 i/o processor has been changed from 105 c to 95 c. 22. internal clock misalignment issue: due to non-core erratum 62, internal clock misalignment can cause processor hang, on page 41 , intel is screening parts to eliminate the probability of occurrence. until this is fixed in a future stepping, a screen has been implemented which will screen out parts exhibiting this issue with a vcc15 greater than 1.46v. with the screen at 1.46v, the on-board 1.5v power rail should not be allowed to go below 1.46v, as this would increase the risk of failure. the 1.5v ra il minimum is currently specified in the datasheet as 1.425v, therefore for screened parts, the minimum is changed to 1.46v. status: fixed. this issue was fixed in the d-1 stepping of the product.
specification update 51 intel ? 80331 i/o processor specification clarifications specification clarifications 1. 64 mb and 2 gb ddr333 capacities not to be tested in post-silicon validation issue: intel is not able to test 64 mb and 2 gb ddr333 dimms due to availability. intel cannot guarantee proper functionality since validation cannot be completed. status: no fix. see the table , ?summary table of changes? on page 9 . 2. ddr-ii 400 unbuffered dimms are not supported issue: the intel ? 80331 i/o processor (80331) supports ddr333 buffered (registered) and unbuffered dimms, but only supports ddr-ii 400 buffered (registered) dimms. ddr-ii 400 unbuffered dimms are not supported. status: no fix. see the table , ?summary table of changes? on page 9 . 3. interrupt behavior in the 80331 no bridge mode issue: when in the 80331 no bridge mode (brg_en = 0), the external interrupts behave just like when the bridge is enabled in the 80331 (brg_en = 1), in that the s_int[d:a]# interrupt inputs can be forwarded to the p_int[d:a]# interrupt outputs. the only difference between the two modes is how the internal messaging unit interrupt is forwarded. in the 80331 mode, it is forwarded to p_intc#, and in the 80331 no bridge mode it is forwarded on p_inta#. status: no fix. see the table , ?summary table of changes? on page 9 . 4. memory map for 2 gbyte of ddr memory issue: the 80331 can support up to 2gbytes of ddr sdram, but it cannot cross a 2gb boundary, therefore it must be mapped to either 0x00000000 - 0x7fffffff or 0x80000000 - 0xffffffff. either range conflicts with one or more of the stati cally assigned regions. the recommendation is to disable the direct outbound atu window, in order to use the larger 2gb memory, by clearing atucr.8 (default setting is ?0? - disabled). status: no fix. see the table , ?summary table of changes? on page 9 . 5. back to back mcu mmr reads issue: the memory controller unit (mcu) returns the wrong memory mapped register (mmr) read data, when two mmr read transactions are enqueued into the transacti on queues at the same time. this cannot happen from the biu port as mapping the mmrs to this space is illegal. the only way this can occur is for two internal bus devices to request info from the mcu mmrs at the same time (with different addresses). for example, the biu (via the intel xscale ? core) and the atu (via the host), which is a very unlikely usage model. status: no fix. see the table , ?summary table of changes? on page 9 .
52 specification update intel ? 80331 i/o processor specification clarifications 6. write requirements for the peripheral bus interface issue: pbi write requirements are: ? must set up the flash or memory to accept writes. ? must ensure the write has occurred before another one starts. ? it is illegal to burst writes to the pbi. the data presented should not be larger than the pbi width. any pbi device should be mapped in the mmu the same. making the device address space cachable can result in buffered/c oalesced writes, which are burst to the pbi. xcb=000 and xcb=001 are the only cache policies that should be used for pbi. all other cache policies result in multi-byte transactions. status: no fix. see the table , ?summary table of changes? on page 9 . 7. pci-x status register during pci mode issue: the pci-x status register (px_sr, offset e4h- e5h) in the atu has meaning only in pci-x mode. the device number and bus number fields are always updated when a configuration write is detected. the atu always grabs ad[15:11] for configuration writes, whether it is in pci or pci-x mode. when a pci configuration tr ansaction occurs, the device number bits (7:3) are updated to a value of ?00000? from the default value of ?11111?. the bus number bits (15:8) are only grabbed during the attribute phase (which does not exist for pci). status: no fix. see the table , ?summary table of changes? on page 9 . 8. m_rst# driven to ddr-ii or ddr-i voltage levels issue: the de-asserted voltage level on m_rst# with ddr-ii is 1.8 volts and with ddr-i is 2.5 volts. when m_rst# is needed for other devices (i.e,. - flash), make sure these voltage levels are appropriate for the target device. status: no fix. see the table , ?summary table of changes? on page 9 . 9. biu master abort causes two interrupts on reads. issue: the b-0 stepping added a bus interface unit (biu) interrupt when the biu gets master aborted on an internal bus write (see erratum # 8 ). the functionality is different between a read and write case. for a write, the biu master abort asserts iintsrc.29 (when enabled) and does not assert an error to the core. for a read, the bi u master abort asserts both iintsrc[29] (when enabled) and an error to the core. therefore, on a read case two in terrupts is generated. when the interrupt source is masked, then only the master abor t on reads is detected, and this is from the direct core error. status: no fix. see the table , ?summary table of changes? on page 9 .
specification update 53 intel ? 80331 i/o processor specification clarifications 10. reset internal bus (pcsr.5) usage issue: pci bus data corruption can occur when the rese t internal bus bit is not used correctly. pcsr.5 can be used to reset the internal bus. this re sets all memory mapped registers and the atu configuration header space. this bit is read/wr ite capable from both the internal bus and pci bus. for both pci and pci-x modes, make sure the following steps occur when setting pcsr.5: 1. clear bus master (atucmd.2) enable and memory enable (atucmd.1). 2. wait for both the outbound (pcsr.15) and inbound (pcsr.14) read transaction queue busy bits to clear. 3. make sure no pci configuration read/write cy cles targeting the atu are in progress, except the reset configuration write, when applicable. 4. set the reset internal bus bit. 5. wait for 40 pci clocks. status: no fix. see the table , ?summary table of changes? on page 9 . 11. no bridge mode (brg_en) validation issue: the brg_en signal (0 = no bridge, muxed on ad[0]) is used to disable the internal bridge, in order to operate as an i/o processor with a si ngle pci-x interface. this feature is not to be validated until after ptq (prototype qualification). note: when central resource functionality is required, then the 80331 needs to be used with the bridge enabled. status: no fix. see the table , ?summary table of changes? on page 9 . 12. potential race condition with interrupt controller unit status bits issue: there is a slight lag in the time it takes between clearing a status bit inside the unit and the corresponding bit in the interrupt controller unit status register getting cleared. this has the potential of generating a false interrupt, meaning that the intel xscale ? core is interrupted but the handler is not able to find any source reported in the icu registers. this condition can be avoided by adding a read from any icu register after the b it is cleared in the local unit before returning from the interrupt handler. the data from this read can be ignored, but the read itself creates enough latency to allow the updated status to propagate to the icu status: no fix. see the table , ?summary table of changes? on page 9 .
54 specification update intel ? 80331 i/o processor specification clarifications 13. bus interface unit follows pci ordering rules issue: the core bus interface unit orders transactions based on pci rules. this allows outgoing writes to pass incoming reads. for most devices on the inte rnal bus, this does not cause problems since the devices function asynchronously with respect to each other. for transactions between the intel xscale ? core and memory via the internal bus, this can result in unexpected data. for example: 0: ldr r0, =0x40000 1: ldr r1, =0xaaaaaaaa 2: ldr r2, =0x55555555 3: str r1, [r0] 4: ? 5: ldr r3, [r0] 6: str r2, [r0] this code could potentially load the register r3 with the value 0x55555555 since the store in line 6 may pass the load in line 5. this only happens with transactions on the internal bus. the mcu core port enforces strict ordering and does not exhibit this behavior. if the mcu core port is used, then this issue will not occur. when caching is enabled, then the initial read will initiate a cache-line fill. the subsequent write is pended in the intel xscale ? core until the line fill and the ldr instruction complete. in this case, this issue does not occur. when caching is disabled, and the caching policy is stall-until-complete (x=0, c=0, b=0), this issue does not occur. for other mmu settings with caching disabled, the issue can occur. specifically regions with data cache and write buffer policies of bufferable (x=0, c=0, b=1) or coalescing-disabled-bufferable (x=1, c=0, b=1) are vulnerable to this issue. in addition, regions configured as write through (x=0, c=1, b=0) are also vulnerable to this issue. in addition, if caching is enabled in the mmu page tables, but the dcache is disabled in the cp15 arm control register, then the effective caching policy is bufferable and this reordering must be accounted for. it is important to realize that any code which accesses memory spaces on the internal bus need to account for this possibility. code which dynami cally disables cache (i.e. - flash programming routines) needs to ensure that the caching policy fo r the appropriate memory region is set to ?stall until complete? until the cache is re-enabled. the simplest scenario to reproduce this is two back-to-back function calls, for example: main: bl fun1 bl fun2 ? ? ? fun1: stmfd sp!, {r4, r5, r6, r7, r8, r9, r10, lr} ldmfd sp!, {r4, r5, r6, r7, r8, r9, r10, pc} fun2: stmfd sp!, {r4, fp, ip, lr} ldmfd sp!, {r4, fp, ip, pc}
specification update 55 intel ? 80331 i/o processor specification clarifications status: no fix. see the table , ?summary table of changes? on page 9 . 14. uart, i 2 c and gpio memory mapped registers should be addressed with 32-bit accesses issue: the uart, i 2 c and gpio units sit on a dedicated low speed internal bus that does not support byte enables. due to this functionality, accessing an y of these unit memory mapped registers (mmr) with any accesses less than 32-bits can result in co rruption of the other bits in the 32-bit mmr. for example, beginning with c-0 stepping, the gpod register (located at ffff_f788h) added new bit functions to bits 10 and 11. when software does a byte access to gpod, this could cause bits 10 and 11 to be written with incorrect data. while most of these registers only implement the lower 8-bits (the upper three bytes are ?reserved?), the recommendation is that all uart, i 2 c and gpio mmrs should only be accessed as 32-bit registers. while it is desired that 32-bit accesses be performed, it is acceptable to access with less than 32-bits, as long as all non-re served bits are accessed. for purposes of future expansion, 32-bit accesses are preferred. status: no fix. see the table , ?summary table of changes? on page 9 . 15. flash wait states issue: the address-to-data wait state and recovery cycle wait state fields in table 60 (pbbar0) and 62 (pbbar1) are incorrect in the intel ? lindsay i/o processor component specification , rev. 2.0, vol. 2. the address-to-data wait state is actually one more than listed, and the recovery cycle wait state is actually two more th an listed. see documentation change # 8 for more specific information. status: no fix. see the table , ?summary table of changes? on page 9 . 16. uart interrupt identification register issue: the uart interrupt identification register (uxiir ) is read by software to determine the type and source of uart interrupts. this register gathers and priority encodes the various sources of uart interrupts. the register is read after an interrupt occurs. enabling and disabling of interrupts (via the interrupt enable register - uxier or mode m control register - uxmcr) effects whether or not the interrupt to the processor occurs. this does not effect the logging of the status of what is happening in the uart. the uart operates in interrupt or polling mode. in polling mode, all interrupts to the processor would be disabled. status: no fix. see the table , ?summary table of changes? on page 9 . 17. reads on 16-bit pbi bus operate as 32-bit issue: 2-byte and 4-byte read transactions on the peri pheral bus interface (pbi) bus operate as burst reads (in other words, two 16-bit read cycles). a ll the read transactions from the intel xscale ? core to pbi devices (in other words, sram, flash, etc.) ar e translated to burst reads with burst size of 2, even though there is no necessity to generate a bu rst transaction. therefore, devices on the 16-bit pbi bus should be configured as pre-fetchable. note: 1-byte transactions on 16-bit pbi bus is not a supported case. also, a pbi bus configured as 8-bit does not operate this way. status: no fix. see the table , ?summary table of changes? on page 9 .
56 specification update intel ? 80331 i/o processor specification clarifications 18. embedded design usage model - secondary pci bus only issue: the 80331, with bridge enabled, can be used in embedded designs that require central resource functionality. the secondary pci bus provides clockouts, arbitration and interrupt inputs for up to four devices. the atu can generate configuration cycles to all devices on the secondary pci bus. in contrast, the primary pci bus cannot be used in embedded designs, therefore no pci devices can be placed on this bus. the primary pci bus was designed to be driven by a central resource only. clockouts, arbitration and interrupt inputs are not provided on the primary pci bus. when the atu generates configuration cycles they are not forw arded from the secondary pci bus to the primary pci bus. also, the intel xscale ? core cannot write to the bridge configuration registers. when using the 80331 in embedded designs, keep the bridge enabled (brg_en=1) and connect the primary pci bus as follows: 1. p_clk is still required. clock frequency should be 66 mhz, since external pull-ups need to be on p_m66en, p_devsel#, p_stop# and p_trdy#. with these signals pulled high, the 80331 is put into conventional pci mode expecting a 66 mhz input clock. if providing a 33mhz clock is easier/cheaper, then tie p_m66en low. 2. p_rst# still required from an external reset source. 3. p_rcomp needs 100 ? to ground 4. with p_req64# tied high, p_ad[63:32], p_par64, and p_c/be[7:4]# have internal pull-ups 5. put pull-ups (8.2 k to 3.3v) on all other primary pci signals. status: no fix. see the table , ?summary table of changes? on page 9 . 19. 3.3 v to 1.5 v leakage issue: there is a leakage path from 3.3 v rail to the 1.5 v rail. when the 3.3 v is powered on and the 1.5 v is not, then ~500 mv is seen on the 1.5 v rail. this leakage is expected and does not cause any long-term reliability issues. for related issues, see documentation change 10 ( ?power sequence timing? on page 66 ) and non-core errata 50 ( ?secondary bus pci rst# pulse prior to the rising edge of p_rst#? on page 36 ). status: no fix. see the table , ?summary table of changes? on page 9 . 20. accessing ?reserved? registers in ?no bridge? mode issue: in general, accessing ?reserved? registers or bit fields must never be done, as these ?reserved? fields might be used for test information or might be implemented in future product revisions. specifically, accessing peripheral memory mapped registers at ffff_f5d0h to ffff_f5dfh when in ?no bridge? mode, causes the 80331 to hang. do not access these registers. status: no fix. see the table , ?summary table of changes? on page 9 . 21. power plane isolation for battery back-up (bbu) mode issue: during battery back-up (bbu) mode, when the battery powers the dimm and the vcc25/18 signals (1.8 v or 2.5 v, depending on the memory type being used) on a single power plane, the battery life is probably reduced, due to leakage. to attain longer battery life, the dimm and vcc25/18 power planes must be isolated. the power-plane isolation can be accomplished by using a fet. status: no fix. see the table , ?summary table of changes? on page 9 .
specification update 57 intel ? 80331 i/o processor specification clarifications 22. aau result can be written directly to pci host memory issue: the application accelerator unit (aau) can write results not only to local me mory but also to the pci bus host memory via the atu. this feature can be applied to degraded raid-5 reads, where the aau result is the reconstructed data for the host i/o read. the aau can write its re sult to pci; therefore, the degraded read xor result can be written directly to host memory. this eliminates the need for a dma operation to transfer the result from local memory to host memory via pci. savings for the raid application include the following: ? no dma descriptor needs to be generated. ? no dma interrupt needs to be serviced. ? memory and internal bus bandwidth is saved (result write by aau and read by dma). ? read i/o is serviced faster (eliminates latency of dma operation). note: aau source reads from pci are not supported; only local memory can be used for this. status: no fix. see the table , ?summary table of changes? on page 9 . 23. pwrdelay functionality during power sequencing issue: when the 3.3 v rail is powered on and the 1.5 v rail is powered off, the pwrdelay input signal drives out until the 1.5 v rail powers up. this is important to understand if still using the legacy power-fail circuit, because it might cause other ci rcuitry to function incorrectly. the proper usage of pwrdelay is described in specification change 11 (?pwrdelay needs only a pull-up for battery back-up mode?), which recommends that pwrdelay be isolated from all circuitry and tied to a 1.5 k pull-up resistor. status: no fix. see the table , ?summary table of changes? on page 9 . 24. pbi lockout condition issue: when the core is in a tight loop writing to the pbi bus, while the dma is doing a large block transfer (for example, from sram , located on the pbi, to ddr memory), the dma can be locked out of accessing the pbi and the transaction will never complete. if this condition occurs, use one of these workarounds: 1. change the mttr1 from 98h (default) to a lowe r value (such as 01h). a lower value allows the dma (or atu which can also master a transaction to the pbi) to gain access to the pbi, because the biu is given shorter access for back-t o-back biu internal bus transactions. 2. add a core read along with the core write, causi ng it to stall and preventing it from starving the dma. 3. add nops or dummy instructions to ensure the loop spans greater than two cache lines. 4. modify the loop such that the write is not done on every iteration. status: no fix. see the table , ?summary table of changes? on page 9 . 25. interleaving descriptors with d-0 aau issue: the p+q capability is enabled in the aau globally (acr.3), not on a descriptor by descriptor basis.
58 specification update intel ? 80331 i/o processor specification clarifications therefore if enabled, all descriptors ar e processed as p+q descriptor formats. if disabled, all descriptors are processed as prior aau definitions (ie - straight xor). in order to mix raid-5 with p+q raid-6, enab le p+q raid-6 gf multiply for the aau, and build all raid-5 xor descriptors as p+q raid-6 descriptors, where the gf multiplier byte values are all 0x01. status: no fix. see the table , ?summary table of changes? on page 9 . 26. rcvdly setting for ddr-i memory issue: the receive enable delay register (rcvdly at ffff_f550h) is used for dqs receive enable calibration. in other words, rcvdly adjusts the memory controllers relationship of dqs to an internal m_clk. the rcvdly value is highly dependant on the bo ard layout and dimm characteristics. also, the memory controller only supports a non integer cas latency (tcas = 2.5, sdcr0.9:8) for ddr-i, which means that rcvdly may need to be adjust ed because dqs is no longer synchronized with m_clk. therefore, when using ddr-i memory, the rcvdly de fault setting of 5 may need to be changed to 6 or 7 to operate correctly with a specific di mm based on the board layout. for example, the redboot reference code provided by intel uses a value to 7 to allow for a wider compatibility with various dimms. status: no fix. see the table , ?summary table of changes? on page 9 . 27. atubar3 functionality issue: the private memory window of the secondar y pci segment defines an address range that the 80331 uses to map private devices to, and to lo cate local memory for private device access. this range is intended to be mapped to the atus private bar window (atubar3) and the private device bars. note that even when the private addressing is enabled, the normal 80331 behavior defined for bme, mse, iose bits in the atucmd register are still true. therefore, when the atu memory space enable bit is cleared, all atu bars including atubar3 will be unable to claim any memory transactions. for example, this bit is typically cleared during a pci bus scan / enumeration. status: no fix. see the table , ?summary table of changes? on page 9 . 28. vref isolation for battery back-up (bbu) mode issue: during battery back-up (bbu) mode, the di mm power can be isolated from the 80331 iop power. this isolation should also include the vref signal for the dimm interface. due to leakage, the vref signal for the dimm should be isolated from the vref signal for the iop. this is to ensure that vref for the dimm is not disturbed as the iop powers down when entering battery back-up (bbu) mode. the isolation can be provided by using separate voltage dividers or a fet. for related issues, refer to specification clarification 21 , ?power plane isolation for battery back-up (bbu) mode? on page 56 . status: no fix. see the table , ?summary table of changes? on page 9 . 29. i2c unit enabling issue: software must guarantee that the i2c bus is idle before enabling the i2c unit. failure to do so could result in unstable behavior. the ibmr register can be used to monitor the state of the scl and sda pins in order to determine bus activity. the i2c bus busy bit in the i2c status register (isr.3) can not be used for this purpose, as it is only valid when the i2c unit is enabled. status: no fix. see the table , ?summary table of changes? on page 9
specification update 59 intel ? 80331 i/o processor specification clarifications 30. dma transactions from local memory to a conventional pci target can complete out of order issue: it is possible for the outbound atu to get backed up and retry the dma unit. when this occurs, the possibility exists for dma transactions to complete out of order as each dma has 3 separate data queues and there is no guarantee as to which one of the queues will drain on the retry. status: no fix. see the table , ?summary table of changes? on page 9 31. sbr1 programming with bank 1 unpopulated issue: when using single-banked ddr-ii dimms and the sdram boundary register 1 (sbr1; ffff_e514h) is not programmed to match the sdram boundary register 0 (sbr0; ffff_e510h), the wrong odt signal will become activated. the memory controller provides two odt (on die termination) signals (odt[1:0]) which are used with ddr-ii dimms to turn on termination during writes. section 8.7.6 in the intel? 80331 i/o processor developer?s manual (273942) states, ?if bank 1 is unpopulated, sbr1[6:0] is programmed either with all zeroes or a value equal to sbr0[6:0].? to clarify this statement for single-banked ddr-ii di mms, if bank 1 is unpopulated, then the entire sbr1 must be programmed the same as sbr0. this includes lower bits 06:00 and upper bits 31:30. bits 30:07 are reserved and should not be written. the memory controller compares the entire range of the sbr0 and sbr1 to determine which odt signal to enable. if the upper bits 31:30 in sbr0 and sbr1 do not match, then odt1 will become active instead of odt0. in addition, when bank 1 is unpopulated, sbr1[6:0] should never be zero if sbr0[6:0] is non-zero. status: no fix. see the table , ?summary table of changes? on page 9 . 32. 32-bit writes to unaligned 64-bit addr esses are promoted to 64-bit aligned writes issue: in applications that run the pci bus segment in 32-bit pci mode or 64-bit pci mode with 32-bit targets, write transactions that are on unaligne d 64-bit addresses are promoted to 64-bit aligned writes. the first half of the 64-bit write is on a 64-bit aligned address and has the be# signals disabled. therefore, the write is invalid. the second half on the 64-bit write is a valid write with the be# enabled and the write is to the intended 32-bit address. per the pci local bus specification, revision 2.2, pci compliant devices should ignore the first half of the 64-bit write due to the be# signals being disabled. for devices that support using the i/o window, the 64-bit write does not occur when using the atu i/o window and only the expected 32-bit write occurs. for memory mapped devices, the only option is to run in pci-x mode, where the byte count and starting address are consistent with the actual numbe r of bytes to be written (i.e., 4). when a 64-bit pci-x request gets downshifted, the requester can use the starting address/byte count to recognize that the write request does not cross a dword address boundary and only perform a single 32-bit wide data cycle. status: no fix. see the table , ?summary table of changes? on page 9 .
60 specification update intel ? 80331 i/o processor specification clarifications 33. case temperature clarification issue: internal models indicate that certain elevated case temperatures (tcase) of the 80331 may cause elevated field failures in later years of operation. this clarification is precautionary, as intel has not seen any failures of the 80331 products in the fiel d. internal modeling data indicates that the degree of failure risk decreases with lower operati ng frequency (i.e. ? 500, 667, or 800mhz) and temperature (i.e. ? case temperature). if a failure should occur, it would manifest itself as a hard failure of the i/o processor which can cause a system failure. a detailed analysis of the system operating conditions, specifically case temperature of the 80331 i/o processor, is required. the 80331 should be ru n with tcase temperatures that, over the lifetime of the part, average less than the 95 o c maximum tcase that is currently specified in the intel ? 80331 i/o processor datasheet (273943). tcase recommendations for the 80331: note: tcase temperatures in the table reflect an av erage tcase temperature over the lifetime of the product. status: fixed. this issue was fixed in the d-1 stepping of the product. see the table , ?summary table of changes? on page 9 . frequency 5 year operating life 6 year operating life 7 year operating life 500mhz 95 o c93 o c91 o c 667mhz 85 o c83 o c81 o c 800mhz 79 o c76 o c74 o c
specification update 61 intel ? 80331 i/o processor documentation changes documentation changes 1. table 236 shows incorrect description for twdl field problem: twdl field (bits 13:12) shows ?00? equals ddr-ii type only. workaround: should state ?ddr-i type only? affected docs: intel ? 80331 i/o processor developer?s manual 2. processor device id should be removed problem: page 739, top of the table shows processor device id register. workaround: this register is no longer valid and should be removed, see sp ecification clarification # 7 . affected docs: intel ? 80331 i/o processor developer?s manual 3. core performance monitoring unit (cpmon) section is incorrect problem: incorrect and incomplete information regarding the core performance monitoring unit. workaround: changes include additional control registers (interrupt, overflow, event) and two more counter (pmn2 and pmn3). see the intel xscale ? core developer?s manual (273473), referred to in the manual as ?xsc2? core. affected docs: intel ? 80331 i/o processor developer?s manual 4. uart fifo occupancy register is read only problem: table 312 shows uart fifo occupancy register (uxfor) as ?read/write?. workaround: needs to be changed to ?read-only?. affected docs: intel ? 80331 i/o processor developer?s manual 5. refresh frequency register table is incorrect problem: the values listed in table 230 are incorrect. workaround: should be as follows: 333 mhz: 500h (7.8 s value); a00h (15.6 s value) 400 mhz: 600h (7.8 s value); c00h (15.6 s value) affected docs: intel ? 80331 i/o processor developer?s manual 6. pbi interrupt should be removed problem: pbi interrupt should not be included in the 80331 documentation. workaround: all references to the peripheral bus unit error interrupt should be removed. this can be found in figure 116, intctl1.21, intstr1.21, iintsrc1.21, fintsrc1.21 and ipr3. affected docs: intel ? 80331 i/o processor developer?s manual
62 specification update intel ? 80331 i/o processor documentation changes 7. arb_en has been de-featured problem: the arb_en signal should not be included in the 80331 documentation. workaround: remove all references to the arb_en signal. affected docs: intel ? 80331 i/o processor developer?s manual intel ? 80331 i/o processor datasheet intel ? 80331 i/o processor design guide 8. flash wait state information is incorrect problem: the address-to-data wait state and recovery cycle wait state fields in table 275 (pbbar0) and table 276 (pbbar1) are incorrect. workaround: the address-to-data wait states are defined in bits 4:2. the wait states are actually one more than listed. therefore the fo llowing change applies: 000 - 5 address-to-data wait states 001 - 9 address-to-data wait states 010 - 13 address-to-data wait states 011 - 17 address-to-data wait states others (default) - 21 address-to-data wait states the recovery cycle wait states are defined in bits 8:6. the wait states are actually two more than listed. therefore the fo llowing change applies: 000 - 3 recovery wait states 001 - 6 recovery wait states 010 - 10 recovery wait states 011 - 14 recovery wait states 100 - 18 recovery wait states others (default) - 22 recovery wait states this change also affects table 271, flash wait state profile programming. affected docs: intel ? 80331 i/o processor developer?s manual
specification update 63 intel ? 80331 i/o processor documentation changes 9. sdcr0 and sdcr1 register updates problem: the sdcr0 ( table 236 ) and sdcr1 ( table 237 ) register description needs to be updated. workaround: table 236. ddr sdram control register 0 - sdcr0 (sheet 1 of 2) bit default description 31:28 0h ras: active to precharge duration in mclk periods equation 7: ras = tras - 1 where tras is from spd 27 0 2 reserved 26:24 000 2 rp: precharge command period in mclk periods equation 8: rp = trp - 1 where trp is from spd 23 0 2 reserved 22:20 000 2 rcd: active to read, active to write period in mclk periods equation 9: rcd = trcd - 1 where trcd is from spd 19:18 00 2 reserved 17:16 01 2 edp: data path latency in mclk periods this field should be programmed to 10 2. 15:14 00 2 reserved 13:12 00 2 wdl: write data latency in mclk periods used by the memory controller state machine. see equation 11 . ? 00 = 0 mclk periods (tcas = 2.5) - (ddr-i type only) ? 01 = 1 mclk period (tcas = 3) - (ddr-ii type only) - not supported ? 10 = 2 mclk periods (tcas = 4) - (ddr-ii type only) 11 = reserved where tcas is from spd 11:10 00 2 reserved 09:08 00 2 cas: cas latency: indicates the cas latency used by the memory controller state machine. encoded value based on tcas from spd ? 00 = reserved ? 01 = 2.5 mclk periods (ddr-i type only) ? 10 = 3 mclk periods (ddr-ii type only) - not supported ? 11 = 4 mclk periods (ddr-ii type only) pci iop attributes attributes 28 24 20 16 12 8 4 0 31 rw na rw na rw na rw na rv na rw na rw na rw na rv na rw na rw na rw na rv na rv na rw na rw na rv na rv na rw na rw na rv na rv na rw na rw na rv na rv na rw na rw na rv na ro na rw na rw na attribute legend: rv = reserved pr = preserved rs = read/set rw = read/write rc = read clear ro = read only na = not accessible intel xscale ? core local bus address ffff e504h
64 specification update intel ? 80331 i/o processor documentation changes 07:06 00 2 reserved. 05:04 00 2 odt termination value: determines the termination value of the on die termination for both banks (controlled by odt[1:0] ). applies to ddr-ii sdram memory type only. ? 00 disabled ? 01 75 ohm ? 10 150 ohm ? 11 reserved 03 0 2 reserved 02 varies with external state of mem_type at pci bus reset ddr type: identifies the selected ddr generation of sdram based on the mem_type reset strap. 0 = ddr-ii (supported speed of 400 mhz) - mem_type deasserted. 1 = ddr (supported speed of 333 mhz) - mem_type asserted. 01 0 2 data bus width: indicates the width of the data bus. see section 8.3.3.4, ?32-bit data bus width? on page 458 . 0 = 64 bits 1 = 32 bits 00 0 2 dimm type: selects unbuffered or registered dimm operating modes for the mcu. 0 = unbuffered* 1 = registered note: unbuffered ddr sdram memory subsystems will use the unbuffered mode. table 236. ddr sdram control register 0 - sdcr0 (sheet 2 of 2) bit default description pci iop attributes attributes 28 24 20 16 12 8 4 0 31 rw na rw na rw na rw na rv na rw na rw na rw na rv na rw na rw na rw na rv na rv na rw na rw na rv na rv na rw na rw na rv na rv na rw na rw na rv na rv na rw na rw na rv na ro na rw na rw na attribute legend: rv = reserved pr = preserved rs = read/set rw = read/write rc = read clear ro = read only na = not accessible intel xscale ? core local bus address ffff e504h
specification update 65 intel ? 80331 i/o processor documentation changes affected docs: intel ? 80331 i/o processor developer?s manual table 237. ddr sdram control register 1 - sdcr1 bit default description 31 0 2 dqs# disable: controls the behavior of the strobes as well as the configuration of the dimm. 0 = dqs# enabled for differential operation, emrs bit 10 will be programmed as zero. 1 = dqs# disabled for singled-ended operation, emrs bit 10 will be programmed as one. 30:28 000 2 rtcmd: read-to-command (non-read) turnaround period in mclk periods. ? 010 = 2 mclk periods (ddr-i type only) ? 011 = 3 mclk periods (ddr-ii type only) all other values reserved 27:24 0h wtcmd: write-to-command (non-read) tur naround period in mclk periods. equation 10: wtcmd = tcas + twr + treg where treg = 1 for registered dimm and 0 for unbuffered dimm, tcas and twr are from spd. 23 0 2 reserved 22:20 000 2 rtw: read-to-write turnaround period in mclk periods. equation 11: rtw = tcas + (bl/2) + treg + (tedp-1) = tcas + treg + 3 where treg = 1 for registered dimm and 0 for unbuffered dimm, bl=4, tcas is from spd, and edp=2. note: a programmed value of 000 2 represents a decimal value of eight (8). 19:17 000 2 reserved 16:12 0 0000 2 rfc: refresh-to-active and refresh-to-refresh period in mclk periods equation 12: rfc = trfc - 1 where trfc is from spd 11:09 000 2 wr: write recovery time in mclk periods. ? 000 = 0 - for ddr333 ? 010 = 3 - for ddr-ii 400 (encoding per jedec spec) all other values reserved 08:04 0 0000 2 rc: active-to-active and active-to-refresh period in mclk periods. equation 13: rc = trc - 1 where trc is from spd 03:00 0h wtrd: write-to-read turnaround per iod in mclk periods. equation 14: wtrd = tcas + twtr + treg where treg = 1 for registered dimm and 0 for unbuffered dimm, tcas and twtr are from spd. pci iop attributes attributes 28 24 20 16 12 8 4 0 31 rw na rw na rw na rw na rw na rw na rw na rw na rv na rw na rw na rw na rv na rv na rv na rw na rw na rw na rw na rw na rw na rw na rw na rw na rw na rw na rw na rw na rw na rw na rw na rw na attribute legend: rv = reserved pr = preserved rs = read/set rw = read/write rc = read clear ro = read only na = not accessible intel xscale ? core local bus address ffff e508h
66 specification update intel ? 80331 i/o processor documentation changes 10. power sequence timing problem: section 9.1 of the intel ? 80331 i/o processor design guide describes the power sequence requirement between vcc33 and vcc15, but does not mention any timing parameters. workaround: the following are the power sequenci ng requirements that must be followed: 1. the 80331 requires that the vcc33 voltage rail be no less than 0.5 v below vcc15 (absolute voltage value) at all times during operations, including during system power-up and power-down. in other words, the following must always be true: ? vcc33 >= (vcc15 - 0.5 v). this can be accomplished by placing a diode (with a voltage drop < 0.5 v) between vcc15 and vcc33. the anode is connected to vcc15 and the cathode is connected to vcc33. 2. when a voltage regulator solution is used, which shunts vcc15 to ground while vcc33 is powered, the maximum allowable time that vcc15 can be shunted to ground while vcc33 is fully powered is 20 ms. 3. the maximum allowed time between vcc33 and vcc15 ramping is 525 ms. there is no minimum sequencing time requirement. affected docs: intel ? 80331 i/o processor design guide 11. updated peripheral bus interface (pbi) timings problem: table 27 in the 80331 datasheet must be updated. workaround: table 27 must have the following values: ? tah1 ? ale high time = 15 ns minimum ? tav1 ? ale high to address valid = 0 ns maximum ? tah2 ? ale low to address invalid = 15 ns maximum ? tas1 ? address valid to ale low = 15 ns minimum ? tao1 ? ale low to poe# low = 0 ns minimum ? taw1 ? ale low to pwe# low = 15 ns minimum ? tah3 ? pwe# high to data invalid = 15 ns minimum ? tas2 ? data valid to pwe# high = 6 0ns minimum ? tac1 ? ale low to pce[1:0]# low = 15 ns minimum affected docs: intel ? 80331 i/o processor datasheet 12. atu pm_cap[5] text must be updated problem: table 140, bit[5] reads as follows: dsi ? this field is set to 0 2 meaning that this function requires a device specific initialization sequence following the transition to the d0 uninitialized state. workaround: it must be changed to the following: dsi ? this field is set to 0 2 meaning that this function does not require a device specific initialization sequence following the transition to the d0 uninitialized state. affected docs: intel ? 80331 i/o processor developer?s manual
specification update 67 intel ? 80331 i/o processor documentation changes 13. wdtcr also affected by tmr1[3] problem: the developer?s manual specifies in section 14.4.2.4 that tmrx, bit[3], (where x = 0 or 1) enables or disables user-mode writes to the timer registers (tmrx, tcrx, trrx). however, when tmr1[3] is set, the watchdog timer register (wdtcr) is also disabled from user-mode writes. workaround: tmr1[3] also controls the watchdog timer. affected docs: intel ? 80331 i/o processor developer?s manual 14. split completion message clarification issue: clarification is required for bridge functionality with split completion message. workaround: add this to section 2.2.13.3.3 between the second and third paragraph: ?if the split completion message indicates the occu rrence of a write-data parity error (i.e. - pci-x bridge class and write data parity error index), the bridge asserts perr# and sets the appropriate bits in the status register wh en the transaction completes on th e conventional interface. the 80331 bridge exhibits this behavior for both the pci-x bridge class and completer class transactions. for all other cases in which a non-posted write transaction completes with a split completion message, the bridge terminates the transaction on the conventiona l interface with target abort.? affected docs: intel ? 80331 i/o processor developer?s manual 15. figure 49 in design guide shows incorrect trace length issue: figure 49 in the 80331 design guide shows incorrect trace length workaround: figure 49 incorrectly shows the trace lengt h for dq/dqs/dm as 2.0?-5.0?. the correct trace length is 2.0?-8.0?, as stated in tables 58, 59, and 60. affected docs: intel ? 80331 i/o processor design guide 16. wrong voltage values in table 21 issue: table 21 shows wrong voltage values. workaround: replaced two rows in table 21. the two rows now appear as follows: affected docs: intel ? 80331 i/o processor datasheet (273943-003). 17. sbr1 programming when bank 1 is unpopulated issue: section 8.7.6 incorrectly states: ?if bank 1 is unpopulated, sbr1[6:0] is programmed either with all zeroes or a value equal to sbr0[6:0].? workaround: the sentence should be changed to ?if bank 1 is unpopulated, sbr1[6:0] and sbr1[31:30] should be programmed with a value equal to sbr0[6:0] and sbr0[31:30].? affected docs: intel ? 80331 i/o processor developer?s manual v ol1 output low voltage (ddr sdram) 0.35 v i ol = 12.5 ma ( 1 , 2 ) v oh1 output high voltage (ddr sdram) 1.95 v i oh = -12.5 ma ( 1 , 2 )

▲Up To Search▲

Price & Availability of QG80331M500

	To Download QG80331M500 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .